Risk-adjusted secure software supply chain for a resilient application

With software supply chain digitalization, threats of supply chain cyber-attacks to governments, businesses, and critical infrastructure are increasing. In recent years, based on various market studies, there has been a stark rise in software supply chain attacks, where 2021 has seen about a 300% increase in such attacks backed by various entities, including but not limited to nation states, hacktivists, and external threat actors.

Modern software engineering involves a lot of code reuse through open-source and third-party dependencies. Vulnerabilities downstream can adversely impact organizations and existing solutions lack the ability to manage software supply chain security governance.

Product engineering teams must successfully implement an operating and sustainable “DevSecOps” approach to application delivery. 

The DevSecOps approach

While much has been said about this technology facet of bringing together development, operations and security, product engineering teams have begun to realize that it is easier said than done. Furthermore, executive orders from various governments to have a formal software bill of materials (SBOM), key building blocks in software security and software supply chain risk management are driving organizations to enhance software supply chain security. Not to forget the introduction of pan-industry benchmarks, such as the National Institute of Standards and Technology (NIST), Secure Software Development Framework and the supply chain levels for Software Artifacts (SLSA framework), that insist on maintaining an acceptable level of resilience for software being developed and shipped for consumption by end users.

According to the EY’s Global Information Security Survey report, only 31% respondents agree that their cybersecurity teams are involved right from the start of new business initiatives. The result is that instead of ‘security by design’, whereby cybersecurity is a central consideration right from the start of each new project, the function constantly retrofits protection, which will often lead to imperfect and costly solutions or impractical workarounds. Some of the key challenges of this are:

Signal fatigue

Various industry reports suggest that security teams from large enterprises have an average of 76 security tools, which is higher than the 64 tools reported in 2019. These tools will sometimes provide more vulnerability signal noise than actual vulnerabilities. 

This poses a few questions, like how do the results translate into discernible business-critical risk of production-grade applications in the scope of assessment, and how many of the microservices, APIs or assets could be exploited based on the results identified by security tools? Also, there is a chance of sensitive data getting exposed from a risk perspective for engineering teams to add necessary remediations.

Fail early, fix early

While failing early and fast to avoid cost-intensive rework has been one of the fundamental approaches to DevOps way of building software, in reality, the product teams are grappling with major issues while onboarding security tools in the continuous integration systems, given the high rate of false positives and non-reliability of the test results. Without a correlation engine that contextualizes the vulnerability findings, developers are spending valuable time triaging hundreds of issues and reducing their sprint velocity.

Cultural transformation

The biggest predictor of an organization’s application-security practices is cultural and not technical, as per the DevOps Research and Analysis report 2022. Compared to low-trust, high-blame teams that focus on rules, the high-trust, low-blame teams focusing on performance were 1.6x more effective in adopting related application-development-related security practices in software development lifecycle (SDLC). Empowering product engineering teams to achieve the much coveted “high-trust, low-blame” quadrant requires a balance of tactical awareness and strategic overview that requires time, effort, and conviction.

In the existing set of processes, compromised distributed software updates can result in attackers gaining access to a wide range of systems. If the attackers can manipulate the update, then they can access the entire system. For instance, in SolarWinds, hackers deployed malicious code into an update for the Orion system, which affected over 33,000 users. Also, the lack of governance in open-source projects, over-reliance on third-party developers, shortage of human resources in security, lack of a one-stop solution for all the vulnerabilities also lead to security issues. 

The existing set of processes and technology investments made by product teams and the necessary evolutions in it can help the teams embed security across the board. A good place to start for most teams would be the use of NIST’s Secure Software Development Framework. This framework helps software developers reduce the number of vulnerabilities in a software and lower the potential impact of the exploitation of undetected or unaddressed vulnerabilities. It also addresses the root causes of vulnerabilities to prevent recurrences. This framework is based on four key pointers. 

• Preparing the organization to adopt practices to perform secure software development at the organization level.
• Protect the software from tampering and unauthorized access.
• Producing well-secured software that has minimal security vulnerabilities
• Respond to vulnerabilities identified within the application or its hosted environment

Furthermore, engineering teams should consider adopting a metrics-driven approach while delivering software. These metrics should help product teams gauge the effectiveness of their organization’s performance. These should check the following:

• Lead time taken for code commit changes to be released into production environments
• Mean time to restore a service or a functional component of the overall system
• The periodicity of deploying code to production or an organization releasing it to end users The percentage of changes to production or released to users result in degraded service and subsequently requires remediation 

Unless product engineering teams employ these pertinent measures, they will end up fighting an uphill battle without making real gains and fall short of achieving their objective of scaling security at the same relative speed of application delivery.

In modern software delivery, where application developers can choose from over 37 million open-source components, growing at 73% y-o-y, EY believes that product engineering teams should consider employing a ‘risk-adjusted secure software supply chain’. 

Security by design

The crux of a risk-adjusted secure software supply chain is that application developers, operations engineers and security analysts are equally responsible for building an anti-fragile, highly reliable software that is ‘secure by design’. For this, product engineering teams should consider the following quintessential building blocks to help deliver resilient applications.

Measuring security posture: Security posture of an application should be measured and maintained continuously. Also, the comprehensive risk posture of an application architecture running in production, including all its services, libraries, APIs, dependencies, attack surfaces, and sensitive data flows, should also be measured. The team should be allowed to rapidly identify and prioritize top business-critical risks that exist in applications at any point in time. The process of determining business risk should be automated. 

Quantify and protect SBOM: The team should assess the security and trustworthiness of third-party libraries and dependencies used within the application code. Proprietary code should be secured through period scans and architecture review and should be continuously tested and monitored after the deployment to identify any vulnerabilities. The developing team also correlates design level threats and security vulnerabilities identified in later stages of development to establish reliable feedback loops for better decision making.

Establish transparency: Transparency can be established through the visibility of software systems. An observability system integrates logging, monitoring, and analytics systems to help detect problems in real-time and troubleshoot them. It will also generate an event with a context that will help easily decide the response to the event. The team should collect relevant metrics, events, logs and traces of applications and its underlying components, such as containers, clusters, pods, and other intricate components. Set the context to show inter-service communication that will help in tracing to understand acceptable behavior. Automated agents can be deployed to detect abnormal behaviors and take corrective actions if necessary. 

Caption: Application Visibility Engineering helps report all sensitive data flows within an application, down to the columns and tables that are being accessed by individual services or APIs within a given application architecture.

A secured application

Leveraging these key facets will help product teams contextualize business risk in real time, for the various internal technology components within the applications during development. Thus, the limited availability of security skills does not become a bottleneck for the entire team in ensuring security but guarantees that all relevant stakeholders get to voice their opinions in a constructive manner.

This approach of leveraging a “risk-adjusted secure software supply chain” helps product engineering teams focus only on the top business critical risks, rather than digging the endless rabbit hole of false positives and toolchain noise. Furthermore, it builds greater trust within the team as developers, those in operations and security analysts have a clear understanding of the software bill of materials and optimized security checklists that are tuned for automation. This eventually helps in lowering the overall technical debt across the board, thus creating a path to sustainable and incremental approach to building and delivering rugged applications that are resilient.

Rakesh Anand, Director and Sudarshan Narayan, Senior Manager Technology Consulting, EY India also contributed to this article.