All security flaws should be fixed, right? In an ideal world, yes, all security flaws should be fixed as soon as they’re discovered. But for most organizations, fixing all security flaws isn’t feasible.
A practical step your organization can – and should – take is to prioritize which flaws should be fixed first. To figure out which flaws should take precedence on your remediation “to-do” list, consider defect severity, the criticality of the application, and how easy it would be to exploit the flaw. In other words, which flaws pose real and immediate risk?
Once you’ve determined which flaws should be fixed first – like OWASP Top 10 vulnerabilities – you can create an application security (AppSec) policy to break the build whenever a flaw falls into that category. For example, if an AppSec scan uncovers a SQL injection flaw, it will break the build so that a developer can fix the flaw prior to production.
At this time, developers have three options for fixing the flaw: remediation, mitigation, or acceptance. Remediation fixes a vulnerability using code or configuration changes or patches. Mitigation is used when the primary control is not available or not feasible to implement, so compensatory controls (such as virtual patches with a WAF) are put in place to reduce or eliminate the exploitability of the vulnerability. And lastly, acceptance is used if the vulnerability is declared low-risk and not worth remediating.
As your developers get used to the AppSec policy and are comfortable fixing OWASP Top 10 flaws, you can then add additional policies. But it’s important that you don’t add too many policies at once. (Unrealistically high expectations for flaw remediation can result in developers taking shortcuts to avoid the policies.)
Another way to “fix” flaws is to prevent them from existing in the first place. If you train your developers to write secure code, you can decrease the number of code errors that will need to be fixed later in the software development lifecycle (SDLC). Integrating automated security tools early into the SDLC and providing guidance for fixing security-related defects can also prevent late-stage fixes.
And, if your organization isn’t doing so already, start scanning more frequently. Scanning frequently not only ensures that you’re introducing fewer flaws into your code, but also helps improve time to flaw remediation. In fact, according to our State of Software Security v11 report, scanning frequently can reduce the time it takes to remediate 50 percent of security flaws by 22.5 days.
Bottom line: the best way to fix flaws fast while creating fewer vulnerabilities is to prioritize which flaws to fix first, train your developers to write secure code, integrate and automate security tools early into the SDLC, and scan frequently.
To learn more about AppSec best practices and practical first steps – like which AppSec testing types to deploy first or how to shift left – or for additional information on fixing security flaws, check out our guide, Application Security Best Practices vs. Practicalities: What to Strive for and Where to Start.