Software supply chain exploits have become a growing threat in recent years as cyber threat actors have worked to insert vulnerabilities or malicious code into trusted applications and open source libraries. If successful, this compromised code provides access to the systems and data of every organization that uses the code.

GitHub’s role as one of the premier repositories of open-source software makes it a special target for supply chain attacks. Over the last few years, GitHub has taken steps to protect against attacks targeting the code on its platform.

However, GitHub’s efforts, such as requiring two-factor authentication (2FA), are not enough.  Here are five best practices for securing your organization’s code on GitHub and beyond.

1. Shift security left

Vulnerabilities in production code are a growing issue and the number of newly discovered vulnerabilities increases each year. These production vulnerabilities expose customers to potential data breaches and other cyber threats and create additional work for developers who need to create, test, and deploy patches to close these security gaps.

One of the main reasons vulnerabilities make it to production is that software security often takes a back seat to other priorities during the development process. Developers are incentivized to write code and meet release deadlines, and security is often an afterthought during the testing phase of the software development lifecycle (SDLC), if it is considered at all.

Identifying and remediating vulnerabilities earlier in the SDLC is essential to decreasing the cost of vulnerabilities to an organization and its customers. However, efforts to increase security are only sustainable if they do not create additional burdens and delays during the development process. By integrating software security solutions—such as static and dynamic application security testing—into automated CI/CD processes, an organization can improve application security and decrease the cost of vulnerabilities without negatively impacting release deadlines.

2. Know Your Developer (KYD)

​​Distributed workforces and work-from-anywhere trends are accelerating the importance of developer identity assurance. Organizations are waking up to the fact that protecting developers is not only critical to their brand, but also necessary for the wellbeing and psychological safety of their employees.

Continuous identity protection on company-managed devices, along with strict patching and endpoint protection controls, must become a priority for organizations. The days of BYOD developer systems with loosely managed and long-lived private key material are a thing of the past.

3. Sign your commits

Codebases are constantly changing and evolving as commits are added, modified, and reverted. With tight release deadlines, it can be difficult to enforce change management processes, and commits may be accepted after only a cursory review. This combination of factors makes it difficult to track the current state of the code and to attribute changes to a particular party.

Lack of attribution creates multiple problems for an organization. Acceptance of code from unknown sources may allow an attacker to slip malicious or vulnerable code into a codebase. Alternatively, the inability to identify and consult the developer of a particular function may result in it being removed or modified in a way that breaks the application.

Requiring all code commits to be digitally signed provides authenticity and integrity protections for a corporate codebase. The ability to map a particular commit to a verified corporate identity ensures that it originated from a trusted source and has not been modified in transit. This audit log of signed commits can also be invaluable when investigating a potential incident or troubleshooting an issue in the code.

4. Validate commit origins

The SolarWinds hack clearly demonstrated the risks of failing to ensure the integrity and authenticity of code commits within an organization’s development pipelines. An attacker managed to insert malicious code into an update to SolarWinds Orion, which was packaged up and digitally signed by the company before being distributed to customers.

The SolarWinds attackers didn’t need to fake a signature on the update because their malicious code was inserted within the development pipeline. Protecting against these types of attacks requires the ability to validate that code commits are originating from an organization’s trusted developers and no one else. If code commits must be digitally signed by a verified corporate identity, then inserting malicious code into the development pipeline becomes much more complex.

5. Verify the authenticity of third-party code

All applications incorporate third-party code and libraries. In most cases, using existing code is considered best practice because it speeds development processes and can often result in better-performing, more secure code.

However, the fact that applications are dependent on third-party libraries makes this third-party code a major target for cyber threat actors.  When developing an application, it is vital to create a software bill of materials (SBOM) that identifies the third-party dependencies of your code. This enables verification of the dependencies, ensuring that the code came from the alleged author and that an attacker has not injected vulnerabilities or malicious functionality into the code.

Tie every commit to a verified identity

Identity verification is a vital but often overlooked aspect of software security. If an attacker can insert, modify, or delete code without detection, then an organization and its customers become vulnerable to software supply chain exploits.

Beyond Identity’s Secure DevOps ensures the authenticity and integrity of code commits by tying them to trusted corporate identities. Learn how to secure your corporate GitHub repos by requesting a free demo today.