GitHub’s Efforts to Stop Security Vulnerabilities

To improve the supply chain security capabilities, GitHub announced that it will send a ‘Dependabot’ alert for vulnerable ‘GitHub Actions’. This new feature helps users stay updated and fix security vulnerabilities in the action workflows. 

As shown below, you can receive alerts on GitHub Actions and enable Dependabot by selecting ‘Enable all’ under the code security and analysis tab. 

(Source: GitHub)

According to GitHub, these alerts would be powered by the GitHub Advisory Database. The company said that when a security vulnerability is reported in action, the team of security researchers would create an advisory to document the vulnerability, thereby triggering an alert to the impacted repositories. It also said that these advisories are searchable and free to access.

This is a positive step by GitHub as a well-tuned and secured CI/CD workflow is critical for development teams looking to build more and ship faster. GitHub Actions gives developers access to powerful, native CI/CD capabilities right next to their code hosted on the platform. 

Dependabot alerts for GitHub Actions

The GitHub Advisory Database powers ‘Dependabot’ alerts for the impacted GitHub repositories. If users avail ‘Dependabot’, they are covered with no additional action required. 

As an owner of a ‘GitHub Action’, once you discover a vulnerability, you can start the process of creating an advisory from the security tab in your repository. The GitHub in-house team will review the repository advisory and curate a global advisory when appropriate upon the complete creation of the repository advisory. 

Here’s a quick guide to writing an advisory—

• The GitHub Action uses semantic versioning.  
• You own the repository of the action that you are creating the alert for.
• Package names are put in a specific format such as ‘org-name/repo-name’. (Example: ‘GitHub/GitHub’s favourite-action’) 
• There is just one action in the repository, so it is distinguishable from other actions. 

GitHub Actions 

Presently, GitHub Actions helps teams of all sizes speed their development velocity and increase the reliability of their software. Moreover, customers can scale their efforts to maintain a more secure codebase across their enterprise by combining reusable workflows and GitHub Action policies. This can include limiting which actions can be used in your organisation or enterprise. 

GitHub said that with more than 13,000 actions to select from, there is an opportunity for every team to improve their development process with a GitHub Action. 

(Source: GitHub)

Code-signing to the rescue 

On August 8, GitHub announced that it is planning to support code signing for npm software packages using the code-signing platform ‘Sigstore’. 

Code signing is the process of using cryptography to digitally add a signature to data. The receiver of the data can verify the authenticity of the signature and, therefore, must have come from the signatory. It is more or less like a physical signature, but digital and more reliable. 

In 2021, Google announced the launch of Sigstore, a project in the Linux Foundation that aims to solve this issue by improving software supply chain integrity and verification. 

Why now? 

As per the Sonatype report, such attacks numbered more than 12,000—a 650 per cent rise in 2020, and a year before that, supply chain attacks saw about a 430 per cent increase. Cut to 2022; the number has continued to increase significantly. 

‘Dependency confusion’ attacks have become the most prevalent form of attack. For instance, according to Project Resonance, of the 1,000 organisations whose GitHub accounts were analysed based on their activity levels and star rating, interestingly, more than one in five—i.e., 212 businesses—contained at least one dependency confusion-related misconfiguration in their codebase. 

Out of 38,691 individual repositories scanned by RedHunt Labs, 220 contained files used to store dependencies. The most common issue which surfaced among these were packages with ‘unreachable’, and therefore hijakable, sources. This comprised 169 repositories that had installed packages from expired domains and 126 repositories that contained packages owned by non-existent GitHub or GitLab profiles. 

Another example was the malicious RubyGems package which was used to steal cryptocurrency. The list is neverending. 

No end to open source vulnerabilities

The supply chain exploits publicly-disclosed open source vulnerabilities. Instead of waiting passively for vulnerability disclosures, many hackers proactively inject new vulnerabilities or bugs into open-source projects, which feed the global supply chain and later exploit the vulnerabilities they have created.  

The new security updates from GitHub attempt to resolve these vulnerabilities. But, the question is—can it be successful in its attempts? Because if any of the developers use these packages, the projects are likely to get affected, and there is a high probability that millions of users will be at risk.