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.
