October 24, 2022 Are Vulnerabilities Undermining Your SDLC Security?

Without optimal performance, motivation, skills, and tools, manufacturers’ security can be at risk.

By Bisham Kishnani

Vulnerabilities found in application platforms and third-party libraries have drawn growing attention to application security in the past few years. This, in turn, has put almost constant pressure on DevOps teams at manufacturing facilities nationwide to detect and resolve vulnerabilities in their Software Development Life Cycle (SDLC).

What does all this mean for developers? And how can we improve SDLC security at manufacturing companies moving forward?

Let’s start with the basics. Development teams typically adopt a form of SDLC in order to structure their process and consistently achieve high-quality results. From that perspective, an SDLC is essentially nothing more than a framework, defining the process of building an application and spanning the entire lifecycle of that application from planning to decommission.

While other SDLC models have emerged over the years, many of which are more robust CI/CD and agile, their objective always tends to be the same: to enable the production of high-quality, low-cost software as quickly as possible. To ensure that security is being considered at every stage of development, a Secure Software Development Life Cycle is introduced to define minimum security controls. Each stage will require specialized security testing tools and methodologies, which will continue to run through every stage for each software release.

Such secure SDLC practices are designed to resolve three primary shared security issues: remediation of recurring vulnerabilities that would be costly to remediate once the software deploys; security issues that lie within the design and architecture; and security issues found within components that are integrated into a much larger system.

Secure practices alone, however, are not enough. To fully embrace a mindset that shifts security practices traditionally completed at a later stage of the life cycle into the earlier stages of development, manufacturers’ DevOps must create a team whose members are knowledgeable across different domains within the SDLC and then build a collaborative environment that enables various teams across the entire operation to regard security in a more holistic way. In addition, manufacturers’ processes and their security priorities must continuously be analyzed and improved, given both the evolution and escalation of threats.

With that in mind, many manufacturers have turned to threat modeling to identify all possible avenues of exploitation. Doing so ensures architecture design and development can account for any and all security flaws. Because threat modeling can be extremely time consuming, however, it is important for manufacturers to take a common sense approach to it so that production doesn’t grind to a halt trying to identify every conceivable threat and method of attack.

Manufacturers are also increasingly leveraging open-source tools as a way to keep costs under control while simultaneously maintaining a high level of security. With that in mind, developers are turning to open-source tools such as tfsec:, a static analysis code scanner that can identify potential security issues within Terraform code templates, and Teller, a productivity secret manager for developers, supporting cloud-native apps and multiple cloud providers.

To increase the functionality of applications and the features they offer without taking the time to develop those features in-house, many manufacturers are turning to third-party components. Third-party components represent another available, low-cost option for already overwhelmed DevOps teams. It is essential for developers to recognize, though, that while these components may save time and money, they may also introduce vulnerabilities into the application.

With that in mind, components must be checked for potential vulnerabilities or other issues when they are initially used and then on a consistent basis to assure compliance with the manufacturer’s security assessments. That means scanning everything, including code, configuration, binaries, and any other material in the codebase.

It also means scanning for misconfigurations at all layers of the software, including infrastructure, data, and application framework layers. Manufacturers need to recognize that most security misconfiguration detection tools available in the market today tend to focus only on scanning for misconfigurations within the infrastructure of the software. They don’t cover any misconfigurations present at the data layer and application framework layer. Ignoring those could make the entire system vulnerable.  

Clearly, the security of a SDLC is in the hands of the manufacturer’s DevOps team. Without optimal performance, motivation, skills, and tools, the company’s security can be at risk. Let’s face it, when you add that to the fact that DevOps teams find themselves often overstretched, having to handle security and compliance too can jeopardize their performance and the company’s SDLC. It also explains why it is important to keep developers’ priorities in mind when building security solutions. Doing so will help the manufacturer to stay in control and keep their organization safe.

Bisham Kishnani is Head of Cloud Security and DevSecOps Engineering at Check Point Software Technologies. https://www.checkpoint.com/

Subscribe to Industry Today