Software supply chains and the developers who work on them are under growing attack. Developers, their source code management, and their CI/CD pipelines are proving to be some of the least secure and best paths to impact. It’s easy for attackers to get unauthorized access to the CI/CD pipeline, inject malicious code into your repo, which then gets merged into your main build (Solarwinds and Kaseya as proof).

Despite these very real concerns, many organizations still believe common misconceptions about secure software development best practices, such as that securing the build pipeline is a complicated, impossible process. Let’s address some common myths and misconceptions about securing your software development lifecycle to stop software supply chain attacks...

Myth 1: Whoever set up my CI/CD pipeline probably did it right, why change?

Within an organization, it is common to see that software developers build and own the CI/CD pipeline, and as a result, lack security controls. You need to ask “Who set up my organization's CI/CD pipeline?” IT leadership roles must fully understand the CI/CD pipeline in order to keep the security of your organization on par with other technology companies. The modern DevOps environment is founded on continuous integration, continuous deployment, and without regular, continuous updates, there is room for errors to fly by unnoticed, creating greater, more expensive bugs and code issues later down the line. The lack of passwordless multi-factor authentication is inexcusable at the git commit level—Beyond Identity is the only passwordless MFA solution designed for git commits. 

It's time to be intentional about software supply chain responsibility: by taking a thorough approach to secure access and git commit controls to your CI/CD pipeline, you can notice faster when there’s a failure, and resolve the issue ASAP. 

Learn more: 3 CI/CD Pipeline Security Best Practices

Myth 2: I authenticate my users to my Git environment, so that protects my code.

Many people mistakenly believe that authentication via the GitHub, GitLab, and Bitbucket web interfaces is sufficient to protect their source code. Unfortunately, the login to web is largely uncoupled from the keys typically used to authenticate SSH to the actual repository, or establish valid user standing via self-attested commit signatures. 

Myth 3: Git does not easily tie into corporate security controls.

While Git does have some identity and code signing capabilities, most organizations rarely utilize it. Organizations struggle on this front because most developers utilize personal Git accounts, and as a result, it can be difficult to control authentication to repos and identify corporate identities.

Myth 4: Our engineering team already signs the code artifacts, so we don’t need to sign each Git commit.

Code signing is not the same as Git commit signing. Code signing is typically used to attest to organizational code origin at the binary, script, or package level, while commit signing is used to attest to individual commits or merges to the organization’s source code. Signing the full artifact is like signing the contract without looking at the fine print: who knows what you signed and if what you shipped, is what your developers meant to build. If you do not sign each commit, you are leaving your organization vulnerable to malware injection and cyberattacks. 

Myth 5: Most organizations don’t sign Git commits, so I don’t need to.

If everyone else jumped off of a cliff, would you? Regardless of what other organizations may, or may not, be doing, malware can easily be purchased by adversaries, injected into your codebase, and distributed to hundreds of your customers, costing them millions of dollars annually. No technical knowledge is even necessary to deploy these attacks. While some organizations don’t follow security best practices, it doesn’t mean they are making the right decision. 

Myth 6: If I require developers to sign Git commits, they will gripe and complain 

Quality software engineers are hard to find and even harder to keep. The current market demand is high and there’s a limited supply of talent. Developers have more mobility than ever and are looking for work environments that value them for their contributions and abilities, rather than restrict them to protect corporate intellectual property.

There is a fine balance between good user experience and adequate security, and developers are not afraid to fight for a better experience. Successful devsecops programs must make this consideration a priority and build in a good user experience for your developers. As long as you make the process an easy one, most will accept it as part of the code CI/CD pipeline. The process also needs to be easy to scale and replicate if a developer decides to leave your organization.

Myth 7: Dropbox is the safest place I could think of to store my private keys.

Developers shouldn’t have to be responsible for storing their private keys, they should be focused on developing great code and products. They lack secure, easy-to-use options for storing their private keys after they are generated. If left on their own, most developers end up merely storing them in their local home directories, but it’s arguably safer to put them on Dropbox with their manifold cloud compliance standards, and it is obviously insane to insecurely store such keys in the cloud, even on reputable services like Dropbox. 

Myth 8: My organization is too distributed and we outsource some development, so it’s impossible to sign every source code commit.

Remote work and outsourcing are realities for nearly every development organization. While today’s most common tools make identity assurance difficult across multiple organizations and end user platforms, it is possible to implement strict identity verification. Git repos have become a huge target for attacks, and unless identities are verified, malware can be easily injected into the source code. It is irresponsible to not verify identities in these environments.

Myth 9: Security will slow down software development and hurt my bottom line.

Properly implemented, Git commit signing with traceability to individual corporate identities is no more difficult than the processes to commit code used today, yet it is infinitely more secure.

Myth 10: The executive order has unachievable expectations.

Most security teams will struggle to convert the bullet point guidance of the executive order into actionable next steps, yet the inspiration for the order was a report that recommended cybersecurity standards already used across industries like aviation and healthcare. The most practical starting point is to simply adopt a secure development lifecycle process and attempt to intercept threats as early as practical. While there are many places for improvement, any steps will set your organization up for success down the line and also prevent future fines and regulatory interference.

There are many ways to secure the software development lifecycle. One of the most vulnerable parts today are your developers, their source code management, and their code commits to the CI/CD pipeline. The Beyond Identity Secure DevOps product is designed to shift security left to secure the developer and the code that can be committed to your build pipeline. With a one-time easy setup and automatic signing for engineering teams, it’s a foolproof way of validating that every code commit came from one of your developers to stop malicious code from being injected into your product. That way you don’t have to spend extensive time and resources looking for a needle in the haystack. It ensures that what your developers built, is what you shipped - and it stops malware from being injected into your code in the first place.

Learn more about the Beyond Identity Secure DevOps product here.