By Dotan Nahum

Vulnerabilities found in application platforms and third-party libraries have drawn growing attention to application security in the last few years, putting pressure on DevOps teams to detect and resolve vulnerabilities in their Software Development Life Cycle (SDLC).

Take the NVD (National Vulnerability Database), which tracks and records all significant vulnerabilities published and disclosed by software vendors. It has found a growing trend in the number of vulnerabilities identified over the past five years, with a staggering 20,136 vulnerabilities recorded in 2021 alone (a 9.7% increase compared to the previous year). 

Meanwhile, the CISA (Cybersecurity and Infrastructure Security Agency) states that out of all the vulnerabilities recorded over time, threat actors are currently exploiting 504.

So what does all this mean for developers, and how can we improve SDLC security moving forward? Let’s start with the basics:

What is SDLC?

Development teams adopt a form of SDLC to structure their process and achieve high-quality results consistently. In that sense, an SDLC is nothing but a framework defining the process of building an application. It spans the entire lifecycle of the application, from planning to decommission.

Different SDLC models have emerged since the traditional waterfall model, with the more robust CI/CD and agile models ranking highest in popularity nowadays. But their goal tends to be similar: to enable the production of high-quality, low-cost software as quickly as possible.

How does a Secure SDLC work (SSDLC)?

A Secure Software Development Life Cycle (SSDLC) introduces the security component into the life cycle, thus providing a framework for developers to ensure that security is a consideration at every stage of software development, rather than an after-thought. This approach prevents vulnerabilities from emerging later in the production environment, thus cutting down on the costs of remediating them.

The example of a Secure Software Development Life Cycle defines the minimum security controls that help secure the software at each development stage. Each stage will require specialized security testing tools and methodologies and will continue to run through all the stages for each software release.

Best practices for improving SDLC security

Secure SDLC practices aim to solve shared security issues, including:

  1. The remediation of recurring vulnerabilities that would be costly to remediate once the software deploys
  2. Security issues that lie within the design and architecture
  3. Solve security issues within components integrated into a much larger system

With that out of the way, let’s look at some best practices for improving security in SDLC:

Embrace a mindset shift

The shift-left mindset aims to bring security practices traditionally completed at a later stage of the life cycle, such as testing components, into the earlier stages of development. In other words, we’ve evolved from DevOps to DevOpsSec, to DevSecOps – all by shifting “Sec” to the left. But walking the talk requires a bit more than that. To fully embrace the shift-left mindset, try:

  1. Building a team that has knowledgeable members across different domains within the SDLC
  2. Fostering collaboration amongst various teams across the organization to take into account a more holistic view of security and what it means for your business in particular
  3. Improving processes continuously, considering that threats are always evolving and so should your security priorities and tactics

Use threat modeling with common sense

Threat modeling is a process of looking into the design of systems, how they operate, and how data flows within and amongst all system components during the earliest possible stage of the SDLC, aiming to identify all possible avenues of exploitation. Conducting threat modeling ensures that architecture design and development can account for all the identified security flaws.

But threat modeling usually takes a considerable time to complete since it requires a human touch to determine all possible avenues of attack. In turn, threat modeling can become a bottleneck for the development process when mostly every component of the SDLC is automated and expects every stage to complete quickly, with new releases happening every two to four weeks. So it is advisable to make use of threat modeling with common sense. While it’s good to list out all possible attack avenues, beware of going down a rabbit hole that can hinder production rather than support and secure it.

Leverage open-source, developer-first tools

Leveraging open-source tools is the easiest way to keep costs down while ensuring that you do not compromise on security. But what use is a cheap tool if developers don’t actually want to use it?

Teller is a fantastic productivity secret manager for developers, supporting cloud-native apps and multiple cloud providers if you’re looking for inspiration. It makes it quick, easy, and safe to mix and match vaults and other key stores and use secrets as you code, test, and build applications.

Another noteworthy open-source tool for your security toolbox is tfsec: a static analysis code scanner that can identify potential security issues within your Terraform code templates.

Check for vulnerabilities created by third-party components early 

Third-party components are quick and easy options for developers to introduce additional functionality into their applications without developing the entire feature themselves.

Even though these components can be cheap, they do come with a price: they may indirectly introduce vulnerabilities into the application. So it is best to check these components for vulnerabilities early on within your security assessments and then again, consistently.

In other words: Scan everything! Scan code, configuration, binaries, or any other material in your codebase to uncover issues that are visible and hidden from plain sights. Need some help with that? Our scanning technology is programming language agnostic and supports 500+ different stacks.

Scan for misconfigurations at all layers of software

Most security misconfiguration detection tools available in the market today tend to focus on scanning for misconfigurations within the infrastructure of the software, but do not cover the misconfigurations present at the data layer and application framework layer. Our DeepConfig solution is here to fill that gap. It provides end-to-end software coverage, including infrastructure, data, and application framework layers. This tool goes about searching for potential misconfigurations in well-known solutions such as:

  1. Infrastructure and Data Layer: Elastic, MySQL, Redis, Memcache, etc.
  2. Application Cache Layer: Rails, Django, and more.

Concluding thoughts

Ultimately, the security of a SDLC will depend on the performance, motivation, skills, and tools available for your DevOps team. And let’s face it: DevOps teams find themselves in quite the dilemma, having to work at an increasingly fast pace, often overstretched, and also having to handle security and compliance concerns which can push back performance. It’s a challenging loop. That’s why we keep developers’ priorities in mind when building security solutions to help them stay in control and keep their organization safe. We respect your CI, ensuring an average-sized repo takes CloudGuard Spectral only seconds to scan. Check it out.

 

You may also like