Building a secure SDLC for web applications

Evolution of the software development life cycle

In the pre-web era, the software development process usually had a clear start and finish, progressing in a linear fashion and handing off deliverables from one isolated phase to the next. This traditional waterfall approach meant monolithic releases that took months or even years to deliver. It was also a one-way process with no provision for backtracking to an earlier stage, making it extremely difficult to introduce changes. This lack of flexibility meant that if business requirements changed during the lengthy application development process, the final product could be obsolete already upon release.

To make the software development cycle less rigid, various iterative and incremental SDLC methodologies were created to allow software to be delivered and adapted more frequently. While these still tended to follow the general waterfall model of distinct phases, software functionalities were developed in smaller batches and delivered to the customer incrementally instead of holding everything back until the full project scope was ready. This made it possible to gradually add functionality while also revisiting customer requirements with every iteration and adapting the product as necessary.

The iterative and incremental approach has culminated in modern agile methodologies with continuous integration and continuous deployment (CI/CD). Software development no longer has an end state but is understood to be an ongoing process that repeats as often as necessary. Because the resulting functionality is delivered in smaller chunks rather than a monolithic release for deployment, a DevOps approach is commonly used to make deployment and maintenance an integral part of the development process. 

Security in different SDLC models

In waterfall and its descendant development cycles, all testing was relegated strictly to the testing phase, and this included manual security testing. This meant handing off code for testing, running tests, resolving issues, and then handing off for the deployment phase – a slow and inflexible process. As development methods evolved and accelerated by building ever more automation into build and test pipelines, the dedicated security testing phase became a major bottleneck.

At the same time, the importance of application security grew. In the pre-web era, software security was not a major concern, as most applications had no remote connectivity and tended to be fairly specialized products. When businesses started moving to the cloud and web applications became the foundation of entire business models, it suddenly became necessary to keep them secure while also shortening release cycles to deliver more value faster.

This was when agile development with DevOps really took off, allowing relatively small software development teams to deliver and deploy large and complex applications thanks to extensive automation. While this unlocked massive business opportunities, it also expanded the potential attack surface and left conventional application security testing even further behind. Even today, application security still often takes a back seat to release schedules, with our research showing that as many as 70% of development organizations skip at least some security steps when deadlines loom.

SDLC vs. secure SDLC

The modern SDLC is a pipeline that can’t afford to stop and wait for security. The only realistic way to build secure software is therefore to build security into each step of the cycle from inception to release – and this is how you create a secure SDLC (SSDLC). The diagram below presents a simplified overview of adding security to the development process.

You can think of building a secure SDLC as adding a layer of security insulation to the bare SDLC pipeline. Each stage of the SDLC has corresponding security considerations that need to be built directly into the tools and workflows used in that phase. As a rough guide, here’s what you need to consider to add security practices to all phases of the SDLC:

1. Requirements: Software requirements defined in the planning phase now also need to include security requirements alongside business, performance, and functional requirements. Security risk analysis and assessment is a major part of this.
2. Design: Secure design is fast becoming a necessity to prevent downstream security issues (and now even has its own OWASP Top 10 category). Typical actions in the design phase could be framework selection, architecture analysis, and threat modeling.
3. Development: Following secure coding guidelines and treating security as a crucial aspect of code quality during coding and code reviews are two prerequisites for secure development. With web development heavily reliant on open-source packages, this also means keeping an eye on the security of libraries and other dependencies. 
4. Testing: In a DevOps pipeline, security testing is not restricted to the QA phase of the SDLC. It can start with static analysis at the code level and continue with dynamic testing up to and including production. Importantly, remediation must be considered an integral part of testing to ensure both security and workflow efficiency.
5. Deployment: Secure code is only one aspect of ensuring application security – you also need to define and maintain a secure configuration, perform security assessments, and run periodic security tests to keep up with the latest threats. This can include vulnerability scanning, penetration testing, red teaming, a bug bounty program, etc.

In real life, building your secure SDLC process is likely to be far more complicated, but you can take existing guidelines such as the NIST cybersecurity framework as a starting point – see our post on cybersecurity frameworks in web application security to learn more.

Application security testing in an agile pipeline

Ideally, security should be deeply infused into every step of software design, development, and operations by building a common security awareness supported by effective tools and processes. Meanwhile, back in the real world, many organizations struggle to systematically run any kind of application security testing, not to mention finding the right cybersecurity talent to make it work. The sticking point is automation – the cornerstone of DevOps but a tall order for traditional security testing.

Without a separate testing phase or sometimes even a dedicated security team, the responsibility for running tests, interpreting the results, and coordinating remediation shifts to the security tools themselves – and the software developers who work with them. Because they are feeding results directly into an automated pipeline, security testing products need to minimize false alarms while still finding security issues that need to be addressed. This is where static code analysis tools (SAST) can struggle – while technically easy to build into the development workflow, they often need a lot of fine-tuning to get the number of positives down to a manageable level. By definition, they are also limited to checking the source code, so they cannot find runtime security vulnerabilities.

Dynamic security testing (DAST) provides wider coverage by testing an entire running application environment. Modern DAST solutions such as Invicti are specifically designed with SDLC integration in mind, overcoming a major limitation of legacy DAST tools. Integrating out-of-the-box with popular issue trackers and CI/CD platforms, Invicti uses Proof-Based Scanning to find and automatically confirm as many as 94% of direct-impact vulnerabilities with no risk of false alarms. Depending on where you are in the AppSec maturity model, you can use Invicti at multiple stages of the SDLC pipeline for maximum coverage and combine it with your existing security solutions.

Is SSDLC the same as DevSecOps?

Reading all this, you might be asking yourself about the difference between SSDLC and DevSecOps (or SecDevOps, for that matter). If one is about adding security to the SDLC and the other to DevOps, isn’t it really all the same nowadays, behind the marketing buzzwords?

In a way, it’s about theory and practice. The SDLC is an abstract, high-level model of the software development process, while DevOps is one way of making this process work in an agile environment with limited resources. Similarly, DevSecOps is one way of building security into DevOps to implement SSDLC in practice. There are many ways to get there, but all of them need at least a high-quality DAST solution to act as the automated and agile equivalent of a traditional security testing team.

To learn more about building security into your SDLC, check out our white paper: Why You Need DAST in Your SDLC