Your Application Development Organization Inadvertently Leaves Door Open for Hackers
“Most if not all of the hacker attacks on well-known companies in recent years didn’t come about because of weak perimeter defense. Indeed, perimeter defense has proven to be remarkably good. But nowadays, most attacks happen because of big gaps in the security of the development supply chain. In other words, vulnerabilities and malware enter your company because your developers inadvertently include bad code in the application they develop. “
Your software development organization is mostly driven by time to market. As a result 83% of companies now use outside, open-source libraries and components to create apps faster. However, little is known about the provenance and security of these components.
Furthermore, different teams within your organization often use different versions of the same open-source components, quickly leading to a huge number of permutations of components baked into your mission-critical apps. What makes this even more complicated is that developers often don’t want to be bothered with checking the provenance and quality of the components they use, instead focussing on getting their job done as quickly as possible.
Many large companies nowadays have DevOps compliance teams that are tasked with oversight over the quality and uniformity of the development organization’s efforts. However, they are mostly given a collection of simple tools and utilities instead of a unified supply chain protection suite.
Developers inadvertently introducing vulnerabilities into applications (and then deploying those applications) has become the most common way for hackers to gain access to company systems and data.
The newly created SLSA security framework strives to bring a methodology to improve the security of the development organization and close the door to hacks. SLSA is a security framework, and a collection of standards to prevent tampering and therefore improve the integrity of the development organization. Two important requirements of the SLSA framework are code signing and tamperproof handling of all supply chain metadata.
Code signing means the unique identification of every single component or artifact in a development organization and the tracking of each component as it moves from source, to build, to deployment and back again to source editing. It’s not unusual to find billions of artifacts in the development organization of large company. Therefore, the ability to track and process billions of components every single day is one of the quality characteristics of Supply Chain Protection software, such as Codenotary’s Trustcenter.
Trustcenter fulfills the SLSA requirement of tamperproof handling of provenance metadata by using Codenotary’s immudb immutable database, which the company released into the public domain. It uniquely identifies and tracks every single application component, its provenance, and its dependencies and therefore quickly points to the use of such items outside of compliance policies. Furthermore, it immediately alerts you to the presence of known vulnerabilities so that you can immediately find all uses of these bad components throughout your organization and remove them fast.
Trustcenter has matured over the last years to a degree of scalability capable of handling the workload of some of the largest banks in the US and in Europe and has effectively protected such customers even when bad components were in encrypted application files.