Four Things You Need to Know Before Building a Secure SDLC

Originally published by Dazz.

Written by Rotem Lebovich, Principal Product Manager, Dazz.

The rapid evolution of cyber threats makes security a crucial element of your software development lifecycle (SDLC). When you build applications for employees or customers you need to make sure the final deliverables—and its data they use—are as impenetrable as possible. That means your development, security, and operations teams need to deploy solutions to protect your nascent software through each stage of development, from design and coding to deployment and ongoing performance monitoring.

The good news is that a wide variety of tools scan for threats and security vulnerabilities. The bad news is that the huge number of tools in the market can make it challenging to piece together a cohesive SDLC security program. Consider this example of a DevSecOps architecture:

It's well-crafted, but it's also overwhelmingly complex.

To ensure you’re selecting the right tools and putting them together in an optimized SDLC security architecture, your development and security teams must answer four key questions:

1. What are the key stages of our SDLC?

Define your stages. The SDLC process varies from company to company, but at its most basic level, it typically looks something like this:

Security and development teams need to work together to outline their own SDLC as a starting point.

2. Which types of tools can help us secure each stage?

During the design stage of the SDLC, your dev and security staff plan the system’s architecture, and identify and document potential security risks. Rather than use specific tools to safeguard this process, make sure security is baked into everything that happens in your design and planning processes.

Once design is complete, though, dev and security teams have a wide array of solutions to choose from. The types of tools that support security in each stage of the SDLC—and the acronyms to describe them—include:

Code

• Software composition analysis (SCA)
• Static application security testing (SAST)

Build

• Static container scanning
• Static infrastructure-as-code (IaC) scanning
• Artifact management

Test

• Fuzz testing (“fuzzing”)
• Secrets detection

Deploy

• Dynamic application security testing (DAST)
• Runtime application self-protection (RASP)
• Interactive application security testing (IAST)
• API security

Monitor

• Cloud security posture management (CSPM)
• Cloud workload protection platforms/cloud or dynamic/runtime container scanning (CWPP/CNAPP)
• Application performance monitoring (APM)
• IaC drift detection

3. What do these tools do?

In the code stage of the software development lifecycle, companies may want to deploy SCA, a scanning technique that looks at any open-source software components embedded in, or otherwise touching, the application under development, then identifies known vulnerabilities within them. Another option is SAST. These solutions scan for vulnerabilities in source code.

In the build stage, companies rely on three primary types of tools. Static container scanning systems analyze the contents of a container image for vulnerabilities and policy violations. Static IaC scanning tools proactively analyze infrastructure resources’ configuration files for vulnerabilities and policy violations. Both types of security tools perform their scans before developers deploy and run the container or infrastructure, so they catch vulnerabilities before they reach production. Artifact management systems, meanwhile, store documents, containers, code, and other materials that are used during application development. In some cases, artifact management tools provide vulnerability scanning of the items in their repository.

‍The importance of security considerations in the test process should be apparent. Fuzz testing, or “fuzzing,” gives applications invalid, unexpected, or malformed input in an attempt to discover vulnerabilities or cause the system to crash. Meanwhile, secrets detection tools scan code and other files for patterns that may indicate the presence of sensitive information. Alerts from either of these types of tools inform DevSecOps teams of security issues that require additional attention.

‍During the deploy stage, companies can use DAST tools to scan applications in runtime. Similarly, RASP systems protect applications from attack once they are running by integrating security capabilities directly into the applications. IAST tools observe running applications from the inside, in real time, to detect vulnerabilities in application frameworks and APIs. And tools specifically targeting API security provide authentication, authorization, data encryption, and input validation to protect crucial API connections.

‍Finally, in production and in the monitor stage, organizations can consider utilizing CSPM tools, which continuously examine and compare a cloud environment against configuration best practices and known security risks. CWPP systems analyze configuration and prospective vulnerabilities across an organization’s deployed workloads. APM solutions monitor the performance and availability of software applications in production. And IaC drift detection tools can identify and report on differences between a company’s intended infrastructure configuration, as defined in the code base, and the actual configuration within the deployed infrastructure.

‍4. Which products are available in each category of tool?

The list of security solutions available to protect an SDLC is lengthy and complex—and well outside the scope of a single blog. However, a recent Dazz whitepaper describes a range of solutions for each stage of SDLC security that we’ve delineated. (The same whitepaper provides more detail on each type of tool, as well—it’s well worth the read.)

‍Navigating the world of security tools is challenging, especially considering the size and scope of available options. However, by turning the SDLC described above into a process within which every stage is well-secured, DevSecOps teams can substantially reduce their organizational risk. And who knows, when their SDLC looks like this,‍

they may even sleep a bit better at night, knowing the applications they’re developing are unlikely to result in big, headline-grabbing security surprises.