How Does Application Security Fit Into the SDLC?

TL;DR

Fixing a software vulnerability after release can cost up to 640x more than catching it during coding, so security must be built into every stage of development rather than bolted on at the end. DevSecOps applies 'shift left' thinking, embedding security by design, cross-team collaboration, and automation across the entire software development lifecycle.

Transcript

Welcome back to the Cyber Security Architecture Series. In previous videos, we covered security principles, some of the foundational concepts, and then we started talking about different cybersecurity domains like identity and access management and endpoint security and network security. Today, we're going to talk about application security. So let... Read More

Key Insights

• Essentially all complex software has bugs, and some percentage of those bugs are security vulnerabilities, so all real software will contain security vulnerabilities that must be actively reduced.
• Most vulnerabilities are introduced during the coding phase but are not found until later testing phases or, worse, after release when they are most expensive to fix.
• The cost to fix a bug rises dramatically across the lifecycle, from 1x in the coding phase up to 640x once the software is released and running in the field.
• The traditional linear SDLC separates development and operations with a thick 'over the wall' silo, creating a slow, inflexible process where security is introduced too late.
• DevSecOps wraps the entire cyclical DevOps feedback loop in a security layer, placing security at every phase instead of treating it as a final bolt-on step.
• Shift left thinking means introducing security by design from the very start so the system is resilient to attack, rather than adding security only near release.
• Secure coding practices are prescriptive checklists covering input validation to prevent buffer overflows, authentication, cryptography, and error handling, with OWASP.org providing an industry-standard reference.
• A software bill of materials tracks every component's origin, dependencies, and versions, so when a vulnerability like Log4J hits, teams know exactly where to make fixes and recover faster.

Questions & Answers

Q: Why does all software have security vulnerabilities?

Essentially all software of any real complexity has bugs because nobody writes error-free software. Since some percentage of those bugs will be security vulnerabilities, the logical conclusion is that essentially all software will contain security vulnerabilities. This is why organizations need proactive practices to reduce vulnerabilities rather than assuming code can be written perfectly, and why security testing and secure coding are essential throughout development.

Q: How much more does it cost to fix a bug after release?

The cost of fixing a vulnerability rises dramatically across the software lifecycle. Using the coding phase as the 1x baseline, fixing the same bug once it is in the field can cost, in some cases, up to 640x more. It is vastly more expensive to fix a vulnerability after release than to catch it early, which creates a huge incentive to build security in from the beginning and find defects as early as possible.

Q: When are most software vulnerabilities introduced versus found?

Most vulnerabilities and bugs are introduced during the coding phase, which is not surprising since that is when the software is written. However, they are typically found later, during unit test, functional test, and system test phases, and hopefully fewer are found once the software reaches the real world. The gap between introduction during coding and discovery during testing or after release is what drives up remediation cost.

Q: What is the difference between DevOps and DevSecOps?

DevOps replaces the traditional linear, siloed development and operations split with a cyclical process that doubles back on itself, creating a continuous feedback loop with no 'over the wall' handoff, more agility, and flexibility. DevSecOps goes further by encompassing that whole cycle in a security layer, placing security at every phase. Instead of waiting until the end, security is built in throughout, because security cannot be an effective bolt-on.

Q: What does 'shift left' mean in application security?

Shift left thinking means introducing security earlier in the development process rather than only near release. If you picture the lifecycle as a linear sequence, shifting left puts security at each phase, including design and coding, instead of at the end. It involves security by design, so the system is built to be resilient to attack from the first, along with collaboration among traditionally separate teams and leveraging automation and tooling.

Q: What are secure coding practices and where can I find them?

Secure coding practices are a prescriptive way of specifying how code should be written, covering things like validating inputs to prevent buffer overflows, how authentication is done, how cryptography is used, and what error handling routines to use. They act as a checklist to confirm everything is done correctly. A great resource is OWASP.org, which provides a list of secure coding practices in a widely used, industry-standard document.

Q: Why are trusted libraries important and what is the Log4J example?

Developers no longer write all code from scratch because there is too much to do, so they rely on open-source or proprietary libraries. Not all sources are trustworthy, and even trusted ones need skepticism and inspection. Log4J is a well-known vulnerability that infected many systems because everyone used this common trusted routine, yet it contained an exploitable flaw discovered after release, when fixing it was most expensive.

Q: What is a software bill of materials and why does it matter?

A software bill of materials is like a supply chain record of all the components used in an application, including their origins, the libraries they came from, their sources, the dependencies among components, and the versions used across systems. It matters because versions change and need updating, and when a vulnerability like Log4J hits, the bill of materials shows every place that needs changes, enabling faster recovery and reduced cost.

Summary & Key Takeaways

• All complex software contains bugs, and a share of those become security vulnerabilities. Vulnerabilities are mostly introduced during coding but found during testing or after release. The cost to fix rises from 1x in coding to as much as 640x in the field, creating strong incentive to catch issues early.

• The traditional SDLC runs design, coding, testing, and release in a linear, siloed way with a thick wall between dev and ops. DevOps replaces this with a cyclical feedback loop for agility, and DevSecOps then encompasses the whole cycle in a security layer, applying shift-left security by design, collaboration, and automation.

• Secure coding needs prescriptive practices like input validation, authentication, cryptography, and error handling, referenced via OWASP. Teams should use trusted libraries cautiously, follow standard architectures, study the OWASP Top Ten, and maintain a software bill of materials tracking component origins, dependencies, and versions, as shown by Log4J.