How to secure your applications across the software development lifecycle

Every company either develops or uses software as a core component of its critical business process. Unfortunately, bad actors know this — and they’re quick to take advantage of it. In this three-part series, we’ve already explored how to conquer third-party risks and secure your supply chain. But what about application security?

Applications can be littered with vulnerabilities just waiting to be exploited. Between 2020 and 2021, application-level cyberattacks rose nearly 80%, according to a recent Radware report, while 73% of retail applications contain security flaws. Yet, only 25% are fixed, per Veracode. And the widespread impact of these breaches often isn’t realized until it’s too late.

Gartner 2021 research revealed that “attackers are targeting software development systems, open-source artifacts and DevOps pipelines to compromise software supply chains.” You’ve likely read about major software supply chain attacks like SolarWinds, Kaseya, and Spring4Shell, but what you might not know is that each exhibited development lifecycle issues that set these events in motion. And they won’t be the last.

Software supply chain attacks surged 300% in 2021, per an Argon Security (now an Aqua Security company) study, while BlackBerry research revealed that four in five businesses were informed of a vulnerability or attack in their software supply chain in the last year.

If we want to sufficiently address this growing risk, organizations must take proactive measures to ensure they’re creating and developing secure software. Sadly, that’s not always the driving factor in application development.

Speed over security

Software developers are first and foremost focused on code functionality. But they’re also up against strict deadlines. As such, there are many components of security in the supply chain software development that may be missing during the design and development phases.

To save time, many developers utilize open-source code and third-party libraries, pulling from these repositories into their applications. Ninety-seven percent of commercial code, in fact, contains open source, per Synopsys.

But that begs the question — well, a few actually: How do you know the code that someone else wrote is secure? How can you verify the code is maintained and updated? How many dependencies does that library have that you have no control over?

These uncertainties — and the fact that they often take a backseat during the development process — leave cyber criminals champing at the bit. Sonatype discovered a 700% surge in open-source attacks in the past three years.

Ultimately, software supply chain security starts during the application design process.

Build security into your software development lifecycle

One of the biggest roadblocks to achieving this is that security and development teams are continuously siloed and separated. So, bringing security into the hands of the developers — and embracing legitimate DevSecOps (development, security, and operations) — is imperative.

Composition analysis is a key component that should be diligently adopted and built into the software development lifecycle (SDLC). This allows visibility and governance by the security and development teams alike.

Developers and security team members should partner together to identify and understand how an attacker might target the application. Third-party risk analysis should be continually performed and leveraged to determine appropriate security control integration. Traceability should also be governed by the business owner. This will provide you with a “map” of process steps — including but not limited to software development — which will lead to full observability of associated control points within the application lifecycle.

Additionally, many companies have embraced continuous integration and continuous deployment (CI/CD) for speed to market. In this case, you must implement security within the CI/CD pipeline and development SDLC with tools that provide appropriate levels of visibility and governance.

Best practices to follow

Manually reviewing code is a monumental task — and not an option in today’s world. Additionally, you’ll find that some code vulnerabilities must be accessed and prioritized since some vulnerabilities in open source may have never been exploited in a current implementation.

Your organization should consider these best practices:

• Threat modeling. During the design phase, think like an attacker. Consider how a threat actor might compromise your application and determine ways to mitigate those vulnerabilities before development starts. Make traceability in development and supply chain actions a focal point.
• Developer training. Teach developers secure coding practices. Training should include joint exercises with the security team to ensure governance of the development cycle while supporting the development environment. Using secure development training videos is one option. There are also tools and vendors that can “gamify” the training process to make it more enjoyable for the development team.
• Measure the security and integrity of third-party code. Scan open-source code for vulnerabilities before putting it into your application.
• Leverage application security testing tools. Find software defects and bugs while your applications are in development and during runtime. This includes fuzz testing.
• Penetration testing. Conduct continuous penetration tests on all applications and connected infrastructure. Simulating attacks can help you find and address vulnerabilities.
• Monitor your application in runtime and utilize webapp firewalls and runtime self-protection. This will help you detect and block known and unknown payloads.

As you introduce these practices, do so with the goal of establishing a strong relationship between security and development teams. This will go a long way to support traceability and observability best practices.

As you choose and implement application security testing tools, make sure they can support the full development lifecycle. This must include open-source tools to check code reuse as well as tools continuously checking developed code components. Automate and consider continuous assessment methodologies, and don’t wait until the end of the process to check on security.  Build it into the complete process from the beginning.

The result of the process should yield a software bill of materials (SBOM) that can be used to support compliance for both the development and consumer relationships.

Choosing the right tools for your developers

While security must be prioritized during the application development process, your developers still need to be able to do their jobs. Make sure they have the means to develop as well as the ability to leverage tools embedded in their development environments.

The right tools can perform software composition analysis (SCA) on open source and third-party and closed-source libraries. Functional SCA tools support components like licensing, vulnerability discovery, remediation, reporting SDLC (IDE) integration, policy development and management, and SBOM creation.

Many supply chain applications run with elevated privileges since they perform machine-to-machine communications over application programming interfaces (APIs) and protocols. Teams should ensure least privilege and identify, monitor, and observe communication paths. API security is a focus for many organizations as we head towards 2023.

How SHI can help you secure your applications

SHI’s security team understands organizational risk and business critical applications and is well-positioned to help you effectively secure your applications.

As one of the six pillars of our standardized security program, our Application Security Lifecycle programmatic review can help you understand your current position and any gaps you may have while also recommending tools and procedures that will increase your application’s security posture.

Our approach reviews people, process, and tooling for validation. By understanding your application development tools and processes, we can help you find the right solutions that fit your unique use case. Our Application Security briefing can help uncover technologies that your development team can use to build security in, rather than trying to create patches later.

Bad actors are increasingly taking advantage of vulnerabilities in the software supply chain. And no one wants — or can afford — to be the weakest link in that chain. But if you’re not taking the proper steps to shore up your applications, you run that risk, opening yourself up to possible reputational damage or financial distress.

We can help you avoid all that by working with your organization to save time and money, all while securing your applications. Get started by meeting with our security experts today.