The hacking of software maker SolarWinds in 2020 has continued to have reverberations, serving as a wakeup call for organizations to take stronger steps to secure their software supply chains.
Since then we have seen the White House issue executive orders and industry groups issue calls for stricter standards and better practices aimed at reducing the risk of malicious activity such as code injection targeting the supply chain.
Recently in June, the Center for Internet Security (CIS) released their supply chain security guide, focusing on how to secure sensitive development services such as your source code, build pipelines, dependencies, artifacts, and deployment.
Reading through all of these different sections of the guide, what stood out to me is that this document offered a departure from your standard AppSec standard and best practices in some interesting ways.
For starters, it is less about just testing binaries or checksums to see if the hash has changed on the code. Those are all still important elements of security. But with the shift to cloud, security teams are putting a greater focus on controlling access to their development pipeline.
This means ensuring that only the right people have the right level of access to the right resources, all with the goal to mitigate potential damages should an identity’s credentials be compromised.
This shift in interest by the authors was most strongly felt in section 1.2 with its focus on repository management due to the impact of access to the repos themselves.
We picked out a few of the guidelines in the list to understand what they are aiming to do. Then we mapped out where and how Authomize’s Cloud Identity and Access Security Platform is able to provide continuously monitored policies and tools to help organizations follow these best practices.
For those items on this list that we do not have a policy, we can suggest a manual process or develop a policy that can automate it.
The Guidelines
1.2.1. Ensure all public repositories contain a SECURITY.md file
What is this:
More better housekeeping than enforcement regime, this basic addition can make it easier for users of the repository to know where to direct their security concerns or findings.
What to audit:
It’s pretty straightforward. Simply make sure that you have the file in your repo or its root directory.
How Authomize helps:
Because Authomize is continuously monitoring access privilege use and defined events like the creation of a new repo, Authomize can issue an alert to an admin that they have a new repo to check that the SECURITY.md file is present.
They can also manually review all public repos to make sure they contain a SECURITY.md file with adequate settings.
1.2.2 Ensure repositories creation is limited to specific members
What is this:
The Principle of Least Privilege calls for limiting what users can do to the absolute minimum that they need to fulfill their duties. Creating a repo is an action that should be reserved to a smaller scope of privileged users because of the potential for abuse.
This guideline looks to keep the number of users that can create a new repo to a smaller, hopefully trusted, set up admins, hopefully reducing the risk. On a practical level, limiting the number of repos helps to make the workload of keeping track of them more manageable.
What to audit:
Verify that only a limited number of users can create repositories. The CIS says that these should be trusted and responsible users, but in the era of Zero Trust, we should think more in terms of limiting the number of users vs how much we trust them.
How Authomize helps:
Limiting the number of users that can create repositories depends on your ability to limit their privileges to do so. Ideally, you should restrict this privilege to admins. Authomize can show you all of the admins and those that have elevated privileges.
As a backup, we can also show you who is using their admin privileges and when a new repo is created, giving you better visibility to make more informed security decisions.
1.2.3 Ensure repository deletion is limited to specific members
What is this:
It is debatable whether it is worse to have someone negligently or maliciously creating or deleting repositories, impacting either integrity or availability of data, but reasonable parties can agree that neither situation is far from good.
Similar to how we want to limit who can create repos, restricting the number of folks who can delete repos is critical to preventing data loss.
What to audit
Again, verify that you know who is able to delete repos, ensuring that only a limited number of people who really should have this privilege are able to do so.
How Authomize helps:
While GitHub provides a global setting to block members who are not org owners from deleting repositories, it is best to review this setting and make sure it is set to “off” to stay on the safe side.
GitLab keeps it even more narrow, allowing only owners to delete projects. By tracking who the organization admins are, you will be able to know who can delete projects and monitor them appropriately.
Authomize can help you to find the owners/admins in each application, saving you from having to perform a manual review of each app.
1.2.4 Ensure issues deletion is limited to specific users
What is this:
The CIS team makes the point that controlling who can delete issues is an important security consideration because it can hide malicious activity. We always want to make it harder for bad actors to cover their tracks.
What to audit:
Verify that only users who should have this privilege can delete issues.
How Authomize helps:
In GitHub enterprise repositories, only admins or owners can delete issues. With its centralized view of all your cloud environments, our platform makes it easy to review all existing, and any new, repository admins by using our tags and policies. This streamlines the process of verifying that only the right folks have this access.
1.2.5 Ensure all copies (forks) of code are tracked and accounted for
What is this:
Forks can get messy. Beyond the headaches that they can cause for developers, these copies of your code can be security risks. Not only for the more straightforward data loss. A malicious actor could take a fork, impact the integrity of the code with changes, and then later merge it back. Like we said, messy.
What to audit:
Ensure all copies (forks) of code are tracked.
How Authomize helps:
Authomize tracks activities from across all connected applications and services. By analyzing these activities, we collect data that enables us to know when a fork has occurred.
1.2.6 Ensure that all code projects are tracked for changes in visibility status
What is this:
There are some repositories that we want to share with the world, and some that we want to keep wrapped away for ourselves. When a repo’s visibility changes from one status to another, say from private to public, we should know about it.
What to audit:
Make sure that you are tracking the visibility of your repos, and investigating any changes.
How Authomize helps:
Authomize’s policy engine already offers an existing policy that alerts when a repo becomes public.
1.2.7 Ensure that inactive repositories are reviewed and archived periodically
What is this:
Leaving code repositories open and unused creates risk. You can reduce this risk of data loss and manipulation by taking it out of play and sticking it in your archives.
What to audit:
Make sure that your repos are in fact being used. If not, send them off to the archives.
How Authomize helps:
Authomize leverages our visibility not only over identities but over assets as well to provide the fullest picture of privilege usage. If we look at the access privileges associated with a repository and see that they are not being used, then we can use those insights to decide how to treat them.
This matters because if privileges are not being used, then they should be revoked. Think about it like an “If you don’t use it, you lose it” approach.
Sign up for the Free Assessment to try it for yourself
Mitigating Risks in Weak Links in an Expanding Chain
Moving the development pipeline to the cloud has created a far more collaborative and efficient environment that produces software at a breakneck pace, allowing teams to build and deploy faster than ever before.
But as we have seen time and again, it is not without its risks. And as we add more services and applications to that process, increasing access to more identities (both human and machine), we spread out our supply chain and open ourselves up to more opportunities for illicit access by malicious actors.
In the wrong hands, even a single set of stolen credentials can lead to risky code being pushed into production and impacting the rest of our downstream products and customers.
We need to take steps to ensure that we strengthen every link in our chain, making it more resilient and reducing risk. This means hardening our posture by establishing and maintaining secure levels of privileges for every identity, sticking to best practices and Least Privilege principles.
Visit us to learn more about how Authomize’s Cloud Identity and Access Security Platform can help your organization to reduce and mitigate your supply chain risks.
