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.

(More security tips: Don’t focus on the OWASP Top 10 list)

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.

4. Test your requirements. Assess the weaknesses you outlined in Step 2. Find out what your automated scanning technologies are capable of checking for and what you may need to supplement with additional manual testing, custom automated test scripts or custom scanner rules. Get real assurance that you have checked for all of the issues that your business actually cares about.

5. Go a step further. Think outside of the box. Look for security issues specific to your application that you may not have determined in Step 1. Usually this requires leveraging an application-security expert.

Too many organizations go straight to Step 5 without much thought for the first four steps. While it’s impossible to know all the risks ahead of time, there is mounting evidence that the vast majority of exploited security vulnerabilities are well known and preventable.

(An example of how bad not securing your software can be)

Keep in mind that the process can’t be static. Keep up to date with new risks and compliance standards, and funnel them into the process on a regular basis so that you’re continuously building in security. If penetration tests or an actual breach point to a gap in Step 1, then close the gap with your newfound knowledge and make sure that no future application suffers the same issue. This sort of feedback loop makes sure that your process continues to evolve, and over time the chances of leaving open a well-known risk falls.

This revised model makes the process easier, faster and better for development teams, as it lowers the total number of vulnerabilities developers must check for, reduces the need for remediation, and makes it clear from the beginning what security requirements must be met for the software to be secure.

Rohit Sethi is vice president of SD Elements, a security consulting company. He also created the OWASP Design Patterns Security Analysis project.