Cybersecurity professionals working in application security have been talking about the risk of hard-coded secrets for years now. Hard-coded secrets come in many forms: They might be applied to application programming interface (API) keys, configuration variables, connection strings, or backdoor URLs.
It’s a problem that has proven much more challenging than it might seem. That’s in part because, based on a recent study by GitGuardian (a company on the Acceleration Economy Cybersecurity Top 10 Shortlist), many organizations continue to use manual code reviews to identify and address hard-coded secrets. Maybe they continue to use manual code review because the diverse types of secrets makes it seem hard to automate the process. Maybe it’s a lack of awareness.
Regardless, there is broad alignment that manual reviews do not scale or provide consistent results when it comes to security. The more code we collectively write without leveraging automation more consistently and deeply, the more risk we carry, and the more vulnerable our organizations become.
Which companies are the most important vendors in cybersecurity? Check out
the Acceleration Economy Cybersecurity
Top 10 Shortlist.
Looking at the Big Picture
GitGuardian’s “Voice of Practitioners” study looked at 500 decision-makers across the U.S. and UK and found that 75% have dealt with a hard-coded-secrets leak. That figure is staggering, primarily because of the continued rise in emphasis on automated static analysis and platform-provided security solutions such as Dependabot in recent years. Yet, despite that rise, these figures reveal that manual reviews — with all their flaw — remain prevalent.
Embracing manual reviews within a security-aware culture is a natural first step toward security-focused code analysis. But it doesn’t scale. These figures drive home to me as a CISO that manual reviews are neither getting the job done consistently nor scalably. We need automation, which lets us define controls, patterns, and rules once and then run them consistently on every code commit. This can then be scaled across huge numbers of repositories.
To me, this helps underscore the need to push automated analysis in the software development process. Manual reviews are great. Mandatory peer reviews before merging are better. Blending that with a strong posture around automation is preferred. As more and more organizations around the world write software and manage pipelines, it’s time that this becomes the default approach to reducing risk in the merge, build, and deployment process.
The Automation Journey
As teams investigate and embrace the benefits of automated solutions in their code analysis efforts, it’s important to acknowledge that automation is really a journey and a mindset. In many of my security leadership roles, I’ve observed that many people view automation as a checkbox: They have automation in the code review process, or they don’t. To me, it’s not that simple. Setting up one check or rule and expecting it to cover all edge cases, even in a narrowly defined type of code analysis — such as the detection of hard-coded secrets — is not sufficient.
While setting up automation at your company, ask yourself these questions:
- How many of our repositories does this apply to?
- Are the results fed back to the development teams to act on them?
- Are the results collected in a centralized place for analysis or capturing metrics?
- Are we looking for the right things in our automated reviews?
- How deep are those reviews going?
- Do we have confidence in the automated rules we have in place? If yes, have we tested the results against any benchmarks?
I could go on, but my main point is that automation in the code review process, whether it’s for identifying secrets or some other type of issue, is part of a journey. It’s not something to simply procure and turn on.
Concluding Thoughts
Companies need to begin investing in automated tools to scale this part of the software development process. Manual reviews just aren’t cutting it.
But automation in its most basic form also doesn’t cut it. Leaders need to be thinking about the journey. Where do you need to go? Where do you want to go? What does the risk look like along the way? Once you’ve started to answer those questions, come back to the how, and get to work.
Want more cybersecurity insights? Visit the Cybersecurity channel:
