Using code scanning technology to identify vulnerabilities in software has long been a cornerstone of application security. It’s not uncommon for application security programs in large organizations to go through the hoops of a request for proposal, vendor demos, and eventual tool procurement, just to end up lost when it comes to broadening a code scanning tool’s adoption, and right-sizing its requirement across the organization.
- “How are we going to evangelize its use?”
- “How can we demonstrate a return on our investment to management?”
- “How do we hold the right people accountable?”
There is a repeatable pattern that can be used to answer these questions that enables organizations to remain agile and reduce unnecessary overhead.
Step 1: Know Before You Go
Before rushing off to “beat up” your developers’ code with the latest and greatest security technology, it is important to understand your portfolio of software (applications, micro-services, serverless functions, etc.), and their respective criticality to the business. Knowing details about the software like its network location, data classification, userbase, open source software risk, and regulatory purview can help inform how they should be prioritized for security scrutiny. Blanket policies that span evenly across all developed products create a lose-lose situation: the small, private, low priority applications receive application security overkill, while the public-facing company home page receives inadequate attention. One size of application security attention does not fit all.
Step 2: Define SDLC Insertion Points
There are several options within the Software Development Life Cycle (SDLC) where it might make sense to insert some form of security evaluation: committing code from a local machine to a remote repository, during peer code review, within a build or release pipeline, or after deployment to a given environment, just to name a few. When defining a policy that states how often security checks must happen, it’s equally as important to clarify where they happen, as it’s no surprise that finding and fixing a security flaw earlier is a much more effective use of resources than scrambling right before a go-live. This has come to be known as “shifting left”.
Step 3: Realize Your Game Plan
After you’ve determined how to differentiate business criticality, and where security testing should plug in, the last step before playing ball involves a mapping of risk appetite between the two. Each “bucket” of business criticality should have a corresponding security prescription across each of the identified SDLC insertion points that determines which findings warrant a required action. For example, this could look like a deployment gate to prevent medium and high severity vulnerabilities in external web apps, or a code review step to search for any high severity vulnerabilities in PCI-scoped applications. Keeping instruction easy to follow will improve the overall efficacy of the program and reduce downstream friction across development teams.
After instituting the aforementioned due diligence, it’s off to the races – getting the word out and working together with development teams to turn the vision into reality.
