4 Reasons Why You Should Define Software Security Requirements for Mature Applications

February 2, 2015

There’s a common misconception that security requirements are only useful for net new applications. Most people think once an application has been developed, it’s too late to introduce new security requirements. While you might realize maximum cost effectiveness by building security requirements in right from the start, the reality is that any application can benefit from software security requirements analysis. Here’s why:

  1. New vulnerabilities: Attackers are crafting new ways to break into systems all the time. Eventually, some of these will affect your application. Continuously checking for new security requirements means that you won’t leave your system at risk when the new vulnerabilities come up.
  2. Applications change: Every new feature or refactoring exercise can introduce new risks into the system, and simply using automated analysis tools or time-boxed manual penetration testing isn’t sufficient to capture the risks. Ongoing inclusion of security requirements means that every change to the system upholds the security posture of the system rather than weakening it. Even if your application is relatively stable with very few changes, it just takes one newly introduced risk to expose the entire application to compromise.
  3. Risk assessment: Establishing accurate security requirements means assessing the risk of an application and coming up with corresponding countermeasures. This is similar to a risk assessment, which is usually a manual exercise. With automated requirements generation, you can scale the exercise of risk assessments to a large number of applications very quickly.
  4. Stress relief: Turning implied requirements into explicit requirements means that development, security, and business stakeholders can all determine which security risks are worth addressing and which ones can be accepted. If you’ve ever taken part in a penetration test before deploying to production, you know that arguing about the risk of findings and whether they’re worth fixing under the pressure of release deadlines can be a stressful experience. Articulating security requirements outside of the context of a release deadline means you can decide which risks are worth fixing without having to worry about focusing on meeting your deadline.

Previous Article
Is Your DDoS Mitigation Battle Tested?
Is Your DDoS Mitigation Battle Tested?

The rising wave of DDoS attacks over the past twelve months have impacted many financial service organizati...

Next Article
Women in Tech: Sintia Maria Sanches
Women in Tech: Sintia Maria Sanches

These blogs are about remarkable employees that contribute to Security Compass’s culture in more ways than ...

Learn how you can use SD Elements to integrate security into software development.

Watch Video