Security Bloggers Network 
SBN

Are Your Company Secrets Safe on GitHub? Here’s Why You Need to Request a Complimentary Audit

Avatar photo by Thomas Segura on May 26, 2023

Are Your Company Secrets Safe on GitHub? Here's Why You Need to Request a Complimentary Audit

As a company with a large number of developers, it's highly likely that some of your company secrets (API keys, tokens, etc.) are publicly exposed on GitHub without your knowledge.

Here are 5 reasons why you should request your complimentary audit of secrets leaks on GitHub.com from GitGuardian.

💡
Snowflake, BSH, and Talend have requested a free audit from GitGuardian to assess their GitHub attack surface for potential secret leaks.
Are Your Company Secrets Safe on GitHub? Here's Why You Need to Request a Complimentary Audit
Talend testimonial

1. Many developers = many leaked secrets

If your company has a significant number of developers, chances are high that some of your confidential information, such as API keys and tokens, may be publicly available on GitHub. This implies that anyone on the Internet can access them, posing a significant security threat.

Our annual report, the State of Secrets Sprawl, aims to increase awareness about the extent of the threat posed by secrets sprawl. In 2022, we detected 10 million instances of leaked secrets, which represents a 67% increase from the previous year. Shockingly, one in ten code authors exposed a secret, resulting in an average of 5.5 commits out of every 1000 that revealed at least one secret.

It’s important to acknowledge that even if your company doesn't do open source, chances are your developers do. And a corporate secrets or source code leak on a personal GitHub repo probably has happened in the past – multiple times! None is immune to mistakes, and even experienced developers are often leaking without realizing it. Our audit can help you identify any potential vulnerabilities.

2. Put a number on the problem

Obtaining a complimentary audit can help you evaluate with your company's own data the size of the problem and decide on its priority.

To drive decisions, data is primordial. Cybersecurity is a busy domain, and we know that choices have to be made.

Having visibility is essential for prioritizing, gaining peer approval, and effectively addressing a particular issue. This is precisely why we offer a free audit – to provide you with quick insights that will give you a comprehensive understanding of the problem's actual scope. Your report will resemble the following:

Are Your Company Secrets Safe on GitHub? Here's Why You Need to Request a Complimentary Audit
Are Your Company Secrets Safe on GitHub? Here's Why You Need to Request a Complimentary Audit

Key metrics are highlighted, such as:

  • Active developers in your perimeter: Developers who mentioned your company name on their GitHub profile or use their company email address when pushing code publicly on GitHub.
  • Secrets leaked publicly on GitHub: Secrets are digital authentication credentials granting access to systems or data. These are most commonly API keys or usernames and passwords.
  • Valid secrets present on GitHub: Secrets that can be exploited by persons with malicious intent.
  • Commits scanned: All activity on GitHub is linked to a commit email. We can tie such commit emails to GitHub accounts and hence monitor that account activity.
  • Secrets breakdown by category: Percentage of secrets leaks per category: Private key, Version control platform, Cloud provider, Messaging system, Data storage, etc.
  • Public events: A public event occurs when a private repository is made public. Such an event is sensitive as it discloses the entire history of a repository where sensitive data could be found.

We are confident that security teams are increasingly aware of the severity of sprawled and exposed credentials, but to back up claims, nothing beats data.

Remember that, unlike other application security vulnerabilities, hardcoded credentials accumulate in time. The faster you can take action and stop the bleeding, the less costly for the organization (you can also try our simulator to estimate the cost of doing nothing over time).

Requesting a complimentary audit allows you to evaluate if this is a real priority for your company with your company's data.

3. Benefit from the detection capability of the #1 security app on the GitHub marketplace

Our solution goes beyond just detecting incidents; it is a comprehensive platform for monitoring and resolving incidents.

Based on our experience, most AppSec and Threat intel teams prefer to start tackling secrets sprawl by using their own detection tool, often built on open-source technology. While these DIY solutions can be helpful at first, they often become difficult to maintain at scale, rely on a specific SCM provider, are hard for developers to use, and have siloed remediation processes.

By requesting a complimentary report, you can quickly compare your previous findings with GitGuardian's and make an informed decision. This service is completely free and non-committal, allowing you to compare our solution to any open-source alternatives you may have implemented.

💡
Tip: If you know people working on a secrets detection algorithm, we strongly encourage you to share this article with them: Why detecting generic credentials is a game-changer

4. Revamp your Vulnerability Disclosure Program with a leaked secrets report that can supercharge your efforts

While scanning repositories for vulnerabilities, you may come across numerous hard-coded secrets that require efficient triaging. However, a vulnerability disclosure program (VDP) may not be the most effective tool in this scenario.

VDPs can only recover a few leaks of secrets at a time and at a high cost. To remediate hard-coded secrets, you need a single platform that can quickly identify the issues and resolve them. Our audit can save you valuable time and money by providing you with a comprehensive report in just a few hours.

We can automatically identify valid secrets and triage them accordingly, giving you the full picture in one go.

5. The best way to establish your GitHub security perimeter

To begin securing your GitHub attack surface, the first step is to get an audit. This report will give you a quick overview of your current security status on GitHub.com. Once you receive the report, which typically takes 1-2 business days, the next step is to set up your customized GitGuardian Public Monitoring Dashboard. Check out our demo video for more information:

Our team of code security experts can guide you through this process and provide a tailored analysis to help you focus on the most relevant security incidents affecting your company.

With the GitGuardian platform, you can prioritize and remediate incidents at your own pace. To get started, sign up for a complimentary audit and start securing your most critical secrets or managing those not reported by your existing solutions.

Conclusion

Requesting a complimentary audit of your secrets leaks on GitHub from GitGuardian is a smart decision for any company with a large number of developers.

The audit can help you accurately determine your developer perimeter on GitHub, evaluate the extent of the secrets sprawl problem, and prioritize accordingly.

GitGuardian's solution goes beyond just detection and can save time and money by providing a comprehensive overview in a matter of hours.

It is the ideal way to begin the journey towards secrets-free code and take control of the detection, remediation, and prevention cycle at your own pace. To take the first step towards a more secure GitHub environment, request your audit today without delay!

*** This is a Security Bloggers Network syndicated blog from GitGuardian Blog - Automated Secrets Detection authored by Thomas Segura. Read the original post at: https://blog.gitguardian.com/github-secrets-leak-free-audit/

Thomas Segura
Avatar photo

Thomas Segura

What You Need to Scale AppSec Thomas Segura - Content Writer @ GitGuardian Author Bio Thomas has worked both as an analyst and as a software engineer consultant for various big French companies. His passion for tech and open source led him to join GitGuardian as technical content writer. He focuses now on clarifying the transformative changes that cybersecurity and software are going through. Website:https://www.gitguardian.com/ Twitter handle: https://twitter.com/GitGuardian Linkedin: https://www.linkedin.com/company/gitguardian Introduction Security is a dilemma for many leaders. On the one hand, it is largely recognized as an essential feature. On the other hand, it does not drive business. Of course, as we mature, security can become a business enabler. But the roadmap is unclear. With the rise of agile practices, DevOps and the cloud, development timeframes have been considerably compressed, but application security remains essentially the same. DevSecOps emerged as an answer to this dilemma. Its promise consists literally in inserting security principles, practices, and tools into the DevOps activity stream, reducing risk without compromising deliverability. Therefore there is a question that many are asking: why isn't DevSecOps already the norm? As we analyzed in our latest report DevSecOps: Protecting the Modern Software Factory, the answer can be summarized as follows: only by enabling new capacities across Dev, Sec and Ops teams can the culture be changed. This post will help provide a high-level overview of the prerequisite steps needed to scale up application security across departments and enable such capabilities. From requirements to expectations Scaling application security is a company-wide project that requires thorough thinking before an y decision is made. A first-hand requirement is to talk to product and engineering teams to understand the current global AppSec maturity. The objective at this point is to be sure to have a comprehensive understanding of how your products are made (the processes, tools, components, and stacks involved). Mapping development tools and practices will require time to have the best visibility possible. They should include product development practices and the perceived risk awareness/appetite from managers. One of your objectives would be to nudge them so they take into account security in every decision they make for their products, and maybe end up thinking like adversaries. You should be able to derive security requirements from the different perceptual risks you are going to encounter. Your job is to consolidate these into a common set for all applications, setting goals to align the different teams collaborating to build your product(s). Communicating transparently with all relevant stakeholders (CISO, technical security, product owner, and development leads) about goals and expectations is essential to create a common ground for improvement. It will be absolutely necessary to ensure alignment throughout the implementation too. Open and accessible guardrails Guardrails are the cornerstone of security requirements. Their nature and implementation are completely up to the needs of your organization and can be potentially very different from one company to the other (if starting from scratch, look no further than the OWASP Top10). What is most important, however, is that these guardrails are open to the ones that need them. A good example of this would be to centralize a common, security-approved library of open-source components that can be pulled from by any team. Keep users' accessibility and useability as a priority. Designing an AppSec program at scale requires asking “how can we build confidence and visibility with trusted tools in our ecosystem?”. For instance, control gates should never be implemented without considering a break-glass option (“what happens if the control is blocking in an emergency situation?”). State-of-the-art security is to have off-the-shelf secure solutions chosen by the developers, approved by security, and maintained by ops. This will be a big leap forward in preventing vulnerabilities from creeping into source code. It will bring security to the masses at a very low cost (low friction). But to truly scale application security, it would be silly not to use the software engineer's best ally: the continuous integration pipeline. Embed controls in the CI/CD AppSec testing across all development pipelines is the implementation step. If your organization has multiple development teams, it is very likely that different CI/CD pipelines configurations exist in parallel. They may use different tools, or simply define different steps in the build process. This is not a problem per se, but to scale application security, centralization and harmonization are needed. As illustrated in the following example CI/CD pipeline, you can have a lot of security control steps: secrets detection, SAST, artifact signing, access controls, but also container or Infrastructure as Code scanning (not shown in the example) (taken from the DevSecOps whitepaper) The idea is that you can progressively activate more and more control steps, fine-tune the existing ones and scale both horizontally and vertically your “AppSec infrastructure”, at one condition: you need to centralize metrics and controls in a stand-alone platform able to handle the load corresponding to your organization’s size. Security processes can only be automated when you have metrics and proper visibility across your development targets, otherwise, it is just more burden on the AppSec team's shoulders. In turn, metrics and visibility help drive change and provide the spark to ignite a cultural change within your organization. Security ownership shifts to every engineer involved in the delivery process, and each one is able to leverage its own deep (yet partial) knowledge of the system to support the effort. This unlocks a world of possibilities: most security flaws can be treated like regular tickets, rule sets can be optimized for each pipeline based on criticality, capabilities or regulatory compliance, and progress can be tracked (saved time, avoided vulnerabilities etc.). In simpler terms, security can finally move at the DevOps speed. Conclusion Security can’t scale if it’s siloed, and slowing down the development process is no longer an option in a world led by DevOps innovation. The design and implementation of security controls are bound to evolve. In this article, we’ve depicted a high-level overview of the steps to be considered to scale AppSec. This starts with establishing a set of security requirements that involve all the departments, in particular product-related ones. From there it becomes possible to design guardrails to make security truly accessible with a mix of hard and soft gates. By carefully selecting automated detection and remediation that provide visibility and control, you will be laying a solid foundation for a real model of shared responsibility for security. Finally, embedding checks in the CI/CD system can be rolled out in multiple phases to progressively scale your security operations. With automated feedback in place, you can start incrementally adjusting your policies. A centralized platform creates a common interface to facilitate the exchange between application security and developer teams while enforcing processes. It is a huge opportunity to automate and propagate best practices across teams. Developers are empowered to develop faster with more ownership. When security is rethought as a partnership between software-building stakeholders, a flywheel effect can take place: reduced friction leads to better communication and visibility, automating of more best practices, easing the work of each other while improving security with fewer defects. This is how application security will finally be able to scale through continuous improvement.

thomas-segura has 67 posts and counting.See all posts by thomas-segura