Software suppliers must set up and maintain security from the get-go rather than wait until there is a breach to fix it. The more software that is released without getting assured, the chances are higher that security risks will turn into full-blown breaches. These invisible risks are security debt that should be discovered and addressed before each release.
“Shift left” security promotes security implementation from the start of the software development lifecycle. From the moment there is clear product value defined, product managers must consider security long before software testing occurs. Threat modelling is an excellent way to do this at the software architecture stage.
Threat modelling is like the reconnaissance work a bank robber does before trying to break into a vault, steal the money and get away without being caught. Whenever architecting software solutions, it is important to assess similar entry points into the software.
“What materials were used to secure the bank’s windows?” becomes “what non-functional requirements are implemented into the web application’s security architecture so that cross-site scripting attacks can’t happen?” Whatever was not implemented is security debt.
What if the bank adds a new wing to support customers? What if the software adds new features supported by new microservices? The security debt is potentially increasing every single time there is a change to the product or its infrastructure.
Recent major cyber attacks have highlighted the necessity for businesses to adopt a zero-trust security model with their products and services. If the bank shouldn’t trust its visitors or even its staff by default – by incorporating strong identification and authentication procedures to access secure areas such as the vault – then software shouldn’t blindly trust its own internal data flow.
Continuous security validation
IT professionals expect web and mobile apps to be kept up to date with the best features. They also expect results without sacrificing security. Data breaches, regulatory compliance and reputational risk have created the new normal. Businesses must take security threats seriously or lose consumer, business and regulator trust.
In certain contexts, compliance standards don’t leave trust to choice – the Payment Card Industry Data Security Standard requires compliance audits for payment card networks through vulnerability scans conducted by an approved scanning vendor.
With the increased adoption of agile software delivery models supporting incremental change, are businesses going to request penetration tests for releases that might occur every two to four weeks? Traditional pen testing provides deep security testing coverage alongside automated methods of static application security testing and dynamic application security testing, but continuous security is required for shorter release cycles.
Stay secure to stay relevant
Software delivery and product managers responsible for supplying IT software can maintain both product relevance and product security by integrating threat modelling, application security testing and other compliance assurance into their existing delivery pipeline.
Without taking these steps during the release cycle, the risk of ever-accruing security debt remains real, and for what – just to stay relevant?
Once a cyber attack occurs, especially one that would have been easily preventable, can IT developers say it was worth not addressing the risk? If they flatten the security risk curve by securing their release cycles, they will never have to ask.
