Development teams are often saddled with the added responsibility of securing the software they’re developing, as many organizations don’t have dedicated application security personnel who can oversee this process.
This creates a lot of extra work for the developer and can undermine their production schedules. It’s made worse by the fact that most companies rely on a verification process for determining software security (using static analysis, dynamic analysis and penetration testing), which forces developers to waste time and money finding and fixing threats that they could have simply avoided in the first place by meeting certain software security requirements earlier.
This practice is also heavily redundant, as development teams must go through dozens, hundreds or even thousands of findings from these assessments, even if they’re not relevant to their specific company or product. And after all that, any specific verification process is bound to miss a lot of serious threats.
There’s a better way to do this. Instead of following the standard model, development teams should flip the model on its head by adopting a clearer process that better identifies and addresses risks that are relevant to your specific application:
1. Identify the CWE. Understand the specific well-known weaknesses (i.e., Common Weakness Enumeration, or CWE) that may affect your software. Keep in mind the OWASP Top 10 is insufficient for this purpose because several of the Top 10 are simply too coarse-grained. You can use the OWASP Secure Coding Practices—Quick Reference Guide and work backward from the OWASP Application Security Verification Standard, or use a commercial Software Security Requirements platform for this purpose.
2. Prioritize risks. Figure out which weaknesses are actually worth remediating for your business, based on their inherent risk and estimated cost to fix. You may want to use a lightweight risk-modeling process such as Threat Modeling Express for this. For example, perhaps you are comfortable with transmitting confidential data through URL parameters because you think the risk doesn’t justify the effort to fix. It’s much easier to have a conversation about what risks your organization is willing to accept and which ones it’s determined to fix when you aren’t facing the pressure of responding to an audit. Just remember, some risks are worth taking for non-mission-critical applications, particularly when you are trading off building features for security requirements.
3. Security controls. Build in security controls to mitigate the weaknesses from Step 2. You can derive controls by looking at the OWASP Secure Development Guide. For agile and continuous integration processes, you can add these controls incrementally, starting with mitigating the highest-risk issue. For legacy code or third-party software, this may not be possible. Instead, you may look into Web application firewalls, increased log monitoring, or other controls to help mitigate risks.