In today’s model of distributed software in the cloud, engineering teams are developing, building, and delivering all the time. Plus, with continuous integration and continuous delivery (CI/CD) pipelines, there are no stopping points for manual security checks. Once the entire build is complete, it’s even more difficult, time-consuming, and resource-intensive to check the entire build for malicious code because then you’re looking for a needle in the haystack. Even if you find a vulnerability, there’s no code provenance and nonrepudiation is nonexistent. Most security organizations we speak to, especially those at high-growth software companies, need to protect their customers that are using their products. They need to be able to validate the integrity of the build and ensure that no malicious code is injected. 

As evidenced by the rise in costly software supply chain attacks such as Solarwinds and Kaseya, malware can be easily injected into the source code. Git repos have become a big target for attackers, which makes sense — it’s an efficient way to gather critical data from a company and all of its customers. Attackers can simply infiltrate the Git repo, inject a malware package, and have the company deliver it to all of their customers using the software. 

What makes it difficult for organizations to protect against these supply chain attacks at the developer level is that most developers have personal Git accounts. And because developers have created these accounts themselves, it’s difficult to control authentication to repos and downright impossible to tie these usernames to corporate identities. Even more, it’s difficult to know whether they are authorized to access the system that they checked the source code into, which is a huge security concern. 

For the few companies that do sign source code today, there are limited options. Either developers create their own personal keys which aren’t tied to a corporate identity, or the keys are centrally created and then distributed to developers to store themselves. This leads to key sprawl and keys being easily moved or stolen, meaning these keys can’t be trusted. Even if a developer creates their own GPG keys, they’re able to login to your organization’s repo and sign their code as “Doctor Strange.” No offense to Marvel, but I don’t want Doctor Strange committing code to my repo. In addition, developers shouldn’t be responsible for storing their own keys (otherwise they might end up being stored in DropBox). Engineering teams should spend their time developing and coding. Modifications to the CI/CD processes should help speed up software velocity.

Beyond Identity’s New Secure DevOps Product

That’s why we’re excited to share our new Secure DevOps product to defend against supply chain attacks and to shift left to secure the software development build process. This novel solution tracks every code commit and ensures that only validated engineers who are using GPG keys tied to their corporate identity and to their authorized devices can commit code. Secure DevOps stops attackers from injecting malware and ensures what your developers submitted to the repo, is what you shipped. 

When integrated into the CI/CD pipeline, the Beyond Identity verification API checks the signature of each code commit and validates the developer’s identity using the Beyond Identity Authenticator on the authorized device. This is the most secure way to verify a developer’s identity because the GPG keys are minted on the device, the private key is stored in the TPM or secure hardware of the device, and the private key can’t be moved. Beyond Identity takes care of the registration of the associated public key to the Beyond Identity Cloud so security teams can set centralized, automated policies for enrollment, key creation, and key revocation.

Proving the chain of custody at the source code level is crucial to ensure that only what your developers coded, is what you shipped. With Beyond Identity’s Secure DevOps, every Git commit is signed with a key that is cryptographically tied to a valid corporate identity. This provides validated code provenance and nonrepudiation for forensic and auditing. Only code commits that are signed by a corporate identity with the Beyond Identity Authenticator and GPG keys on an authorized device can successfully commit code, which stops adversaries from injecting malicious code into your CI/CD pipeline.

What sets Beyond Identity’s code commit signing apart is the ease of setup and use for engineering teams. It’s a seamless experience for development teams: developers set it up once and then Beyond Identity signs code commits in the background for all authorized users. It’s scalable and doesn’t impact software velocity. As long as developers have enrolled their authorized devices, they’ll be able to commit code as fast as they can write it. Code commits only get blocked in the CI/CD pipeline when unauthorized users or devices do not sign it. The feedback we’ve heard, even from our internal team, is that our developers love it. It’s immutable proof of what they individually contributed to the product’s code, and it’s not disruptive to their day-to-day work.

Benefits:

• Achieve code provenance: Confidence that what your developers built, is what you shipped.
• Stop malicious users from committing code into your build: Only corporate identities and authorized devices with the Beyond Identity Authenticator can commit source code. 
• Eliminate key sprawl: High assurance that the corporate user is in possession of the private key and an immutable record of all keys that are created or deleted.
• Get nonrepudiation for forensic analysis: all code commits are signed and only code with verified corporate signatures make it into the build
• Shift security left: Automated security checks at the beginning of the software development lifecycle to verify the user’s identity.
• Integrate with most popular Git repos: Native integrations with GitHub, GitLab, and BitBucket and CI/CD tools

How Beyond Identity Secure DevOps works:

Speed up software velocity, while keeping your developers and code safe. See it to believe it.

Additional resources:

• Product page
• Datasheet
• Security Vulnerabilities in Git Solution Brief