Tech giant Google is throwing its hat in the ring in the when it comes to cleaning up the mess that is software security, unveiling a new framework today that is designed to secure the coding and development process that undergirds modern software, and cut down on the potential for damaging supply chain attacks.

Rather than hone in on ways to defend against a specific attack at a specific point in the software development process, the Supply Chain Levels for Software Artifacts (SLSA, or “Salsa” if you’re looking for a snappy shorthand) is designed as a roadmap for developers to guide their security processes to spot and defend against common attacks at every link in the development and production chain.

Similar to frameworks like the Cybersecurity Maturity Model Certification being implemented by the Department of Defense for its contractors, Google’s framework maps a myriad of processes and practices across four different levels of increasing software security sophistication. It also flags eight points in the development and production workflow that are vulnerable to different forms of corruption.

“It’s about getting people an on ramp, getting them started somewhere, realizing that you can’t just jump all the way up to the highest levels from the start – and not everybody even needs to, depending on what you’re doing,” said Dan Lorenc, a software engineer at Google, in an interview.

The framework is primarily geared towards open-source developers because open-source code “is the [common] link between everyone in the supply chain,” he said. But it can also be applied to aspects of the commercial software development process as well.

It accounts for scenarios like submitting bad or malicious code to source repositories, compromising a build or update server, modifying code as it moves between source control to the build platform, and attacks that bypass the Continuous Integration and Development process. Each weak point is backed up by a real-world attack and explanation of how the framework might have been used to detect or stop the compromise before infecting downstream customers – for example, the hack of the SolarWinds’ Orion build server to inject malicious code into a software update.

Higher levels of SLSA include security controls that either make it more difficult to carry out a similar attack or limit the ability of a threat actor to lurk in a compromised environment over long periods of time. Similarly, there are multiple controls that help establish the provenance of software code and prevent bypassing the CI/CD process, which was how attackers were able to breach CodeCov to get a hold of customer test code and other data.

In a blog post, Google security officials said the idea will serve as general guidance for now, but they ultimately envision a more formal process.

“In its current state, SLSA is a set of incrementally adoptable security guidelines being established by industry consensus,” wrote Kim Lewandowski, a member of Google’s open-source security team and Mark Lodato, who works on securing Google’s internal software process. “In its final form, [it] will differ from a list of best practices in its enforceability: it will support the automatic creation of auditable metadata that can be fed into policy engines to give ‘SLSA certification’ to a particular package or build platform.”

Google’s sheer scale and reach across different software and hardware products give it both skin in the game and the potential reach to bring a large number of companies into compliance. It could also create a powerful tool for a commercial company to wield over potential competitors or rivals.

Lorenc told SC Media that while they are still determining how such a certification program would be structured or implemented, it’s likely that a “vendor-neutral” third party – not Google itself – would be charged with overseeing the certification process.

“I don’t think we have too [many] firm details on that in our heads yet,” he said. “I don’t think it would be something [where] a single company would be overseeing or managing; that probably doesn’t really make sense.”

Right now, the project is being put out for open comment (see here for SLSA’s GitHub page) and Google is actively soliciting outside parties for ways to further improve and standardize the framework to be widely relevant.

We think it’s in a good state where people can start trying to use it, trying to make sense out if it, and then we want to see how it works. We want feedback to harden it and ensure we’ve got everything right,” said Lorenc.

The post A look at Google’s new project to boost security for open source (and other) software code appeared first on SC Media.