Cracking the Code to a Successful Remediation Plan

Creating a remediation plan can be tricky. In fact, customers often tell us that it’s much easier to create a plan to help developers scan applications quickly and easily than it is to establish remediation goals. But if vulnerabilities aren’t remediated right away, there’s a higher chance that they will never be remediated.

Our recent State of Software Security (SOSS) report found that there’s about a 22 percent chance that a flaw will be fixed within a month of being discovered. If it’s not closed in the first month, the probability of remediation falls each month thereafter.

So what are some steps you can take to get started on a remediation plan for developers? First off, keep in mind that developers are responsible for more than just the security of their code, they are also responsible for the speed of deployments. This means that, just like security scans, remediation goals should be easy for the developer to follow and they should take time and resources into account. Second, consider incorporating remediation best practices or tips that have been proven successful, like the list below.

Provide developers with plenty of time to remediate flaws.

Developers need to be testing early and throughout the software development lifecycle (SDLC), preferably with automated scans that are integrated into their existing tools and processes. If developers are scanning early, it will give them the time they need to remediate flaws. If they wait until the end of the SDLC, it will be expensive and time-consuming to remediate flaws, which could dissuade the developer from making the necessary fixes.  

Train developers on secure coding practices and leverage tools that provide real-time feedback and remediation advice directly within the IDE.

Most computer science curricula do not include security. So, when developers join your organization, it’s important that they receive secure code training. By writing secure code from the start, there will be fewer flaws or vulnerabilities for developers to fix down the line. If possible, you should also leverage tools that provide developers with real-time feedback and remediation advice while they code, like Veracode’s IDE scan. Veracode’s IDE scan helps developers remediate faster and learn on the job through positive reinforcement, remediation guidance, code examples, and links to Veracode AppSec Tutorials.

Help developers prioritize flaws based on severity.

Not all flaws are created equal. Some flaws are simply informational and aren’t a real threat to an application, while other flaws are considered “High” severity and need to be remediated immediately. When giving a flaw report to developers, make sure to outline the criticality of the flaws discovered by
mapping the flaws to possible exploitations, explaining what the exploit might mean to the business, and providing tips on what the developer can do to address — and reduce — the risks. For example, as stated in Securosis report, Building an Enterprise DevSecOps Program, you might be able to remediate a critical application vulnerability in code, patch supporting systems, disable the feature if it's not critical, block with IDS or firewalls, or even filter with WAF or RASP technologies. Developers do not understand exposure analysis, so it’s difficult for them to differentiate the severity of vulnerabilities. For flaws that are deemed “High” or “Very High,” consider having the tools break the build so the flaws can’t go unaddressed. For flaws that are not a risk to the business, don’t be afraid to tell the developers to do nothing.

By working with developers to create a remediation plan, and incorporating the tips listed above, more flaws will be fixed, and your applications will be increasingly secure.

For additional information on working with developers to improve your AppSec program, check out our video, Tips for Unifying the Security Professional and Developer Roles.