By clicking “Accept”, you agree to the storing of cookies on your device to enhance site navigation, analyze site usage, and assist in our marketing efforts. View our Privacy Policy for more information.
18px_cookie
e-remove

Your Git Repo is a Supply Chain Risk

Source code repository misconfigurations can expose your organization to supply chain attacks. Repository Security Posture Management (RSPM) can offer a reliable system to enforce best practices.

Source code repository misconfigurations can expose your organization to supply chain attacks. Repository Security Posture Management (RSPM) can offer a reliable system to enforce best practices.

Source code repository misconfigurations can expose your organization to supply chain attacks. Repository Security Posture Management (RSPM) can offer a reliable system to enforce best practices.

Written by
Darren Meyer
Darren Meyer
Published on
April 30, 2024

Source code repository misconfigurations can expose your organization to supply chain attacks. Repository Security Posture Management (RSPM) can offer a reliable system to enforce best practices.

Source code repository misconfigurations can expose your organization to supply chain attacks. Repository Security Posture Management (RSPM) can offer a reliable system to enforce best practices.

Supply Chain Security programs often focus first on “how do we consume less risk from our supply chain”. But your applications (and sometimes, libraries, SDKs, and so on) are part of your users’ supply chains. So how do you ensure that you don’t pose a supply chain risk? 

There’s no silver bullet answer to that question, of course — our jobs can’t ever be that easy! But an important place to start is to ensure that your repository hosting solution has controls in place around the processes of contributing code and related assets to your repositories.

Configuration-Based Supply Chain Risks

The goal of managing your repository configuration is to ensure that controls that make certain kinds of supply chain attacks much harder for your adversaries, both by creating barriers to malicious activity and by making it less likely that your developers and DevOps teams make errors that could open the door for such attacks. Fortunately, many of the controls that help with supply chain attacks are also things that development teams are willing to enforce on their own for other reasons. 

For example, enforcing that certain tests must pass before code can be merged into key branches helps reduce the amount of disruptive debugging developers must engage in before release, by ensuring that a minimum quality bar is met before code is shared widely in the project. The same setting can ensure that necessary security controls — such as open source dependency scanning tools, SAST tools, and so on — are running at the right times.

Other controls are more security-specific, such as ensuring that users of the repository are authenticated with two factors (which is why some vendors, like GitHub are starting to mandate 2FA), or requiring your GitHub orgs to have a “verified” badge to reduce the risk of a form of repo-based typosquatting.

Managing Your Source Repository Configuration

Platforms like GitHub get you part of the way here by allowing you to set “organization”-level rules and security settings. For example, you can create organization-wide branch protection rules that require all commits be properly signed before you merge to main.

Example of branch protection rules
Example of branch protection rules

As your organization begins to scale, though, you find that these built-in controls have some shortcomings, like:

  • It’s complex or impossible to enforce certain “best practices” (like requiring a CODEOWNERS file or requiring a SECURITY.md file on all public repos) in a consistent way
  • Managing exceptions or different levels of control maturity between organization units or types of project is complex — it often requires global settings that are too permissive, and no systematic way to ensure that stricter controls are applied to specific repositories
  • They tend to be preventive only — this makes rolling out a new rule disruptive since it risks breaking developer workflows and you can’t easily test or verify the impact on those workflows before deploying the control
  • Controls can’t easily be unified across organization units. Acquisition or adoption of an organization tends to be “all or nothing” — you can adopt a new organization into an existing one and apply all those rules (with all the risk of breaking workflows for an org that might be at a different maturity level or have different solutions to the same problems), or manage it completely separately
  • Controls are difficult to manage across different platforms (for example, keeping key controls in place as an organization is migrating from a self-hosted GitHub Enterprise to the cloud version, or vice-versa).

What’s needed is a reliable system to analyze the posture of your repository configurations, compare them to centrally-managed policies (ideally, policies that can be different for different areas of your organization), and respond by either creating an appropriate alert or (if it’s critical enough) blocking a merge or release. In short — because security loves our acronyms — you need RSPM.

What Exactly is RSPM?

Repository Security Posture Management (RSPM) is a system and process, supported by appropriate automation, for ensuring that your source code repositories and the platforms that host them are appropriately monitored for security controls and best practices. RSPM isn’t a tool, but an RSPM tool can make much of the program much easier and less-expensive to deploy and operate.

An RPSM system examines the contents and configurations of your source code repositories and compares them against well-defined policies. As with most security systems, RSPM rollouts go through a maturity stairway:

  1. Visibility: Identify the configurations in use, and where they differ from desired baselines. Once monitoring is established, you have the data you need to adjust your target baselines and work with development and DevOps teams to harden their configurations.
  2. Integration & Alerting: Integrate assessment and policy evaluation into DevOps workflows; alert quickly when configurations deviate from baselines, triage the alerts, and assign work.
  3. Active Enforcement: With data gained from operating at the two previous maturity levels, set policies that monitor critical configuration items and block contributions where they don’t comply.

In practice, this often means building or buying automation tools that use your source code platform’s API and to examine configuration settings on each repository, as well as analyzing the repo contents for things like the presence of a SECURITY.md file, collecting what these tools discover, and then comparing the discovered data against an established baseline.

For example, if you’re using GitHub, for your initial rollout you might create a security pipeline that:

  • List all your org’s repositories
  • Calls GitHub’s management APIs to check settings on each and saves a JSON artifact
  • Uses GitHub’s search capabilities to determine if files like SECURITY.md and CODEOWNERS are present
  • Pushes discovered data into a database, BI tool, or similar place that security engineers can analyze it

This security pipeline then would be run as needed, after which a security engineer would compare the data against the baseline to highlight where there are differences against the baseline, and open appropriate remediation tickets in Jira (or whatever task tracking system your organization uses).

A mature RSPM system automates much of this discovery, analysis, and alerting for you, reducing the workload on security and development teams and the overall cost of the program.

RSPM with Endor Labs

Because Endor Labs realizes the importance of managing an effective, low-cost program for RSPM, we’ve built comprehensive RSPM capabilities into our platform. Whether you’re analyzing from a security pipeline or integrating Endor Labs capabilities into your build pipelines, we can analyze your source code repository configurations and enforce centrally defined policies for those configurations.

  • Choose from over 20 pre-built configuration policy items (aligned to CIS benchmarks) to enforce configuration, file presence, and so on
  • Use our flexible, Open Policy Agent (OPA) based policy system to apply different policy sets to your open-source projects, critical applications, etc.
  • Easily develop additional RSPM policies, either using our UI or by publishing your own Rego policy code via our API
  • Centrally report, and route relevant alerts to responsible parties based on policies
Example of some policies for detecting RSPM issues.
Example of some policies for detecting RSPM issues.

Deployment is easy, from no-code deployments using our GitHub App or GitHub Action to simple, low-code integrations with nearly any pipeline system. 

Build a CI/CD Security Program with Endor Labs

In addition to RSPM, Endor Labs CI/CD includes:

  • CI/CD Discovery: Get visibility into tools used in pipelines across your org, understand security coverage, and find policy violations.
  • Artifact Signing: Ensure the authenticity of software artifacts, confirming their source and that they have not been tampered with.

Endor Labs CI/CD is available in our free trial, where you can explore the Endor Labs Software Supply Chain Security platform on a pre-populated demo environment and with your own projects.

The Challenge

The Solution

The Impact

Request a Demo

Request a Demo

Request a Demo

Welcome to the resistance
Oops! Something went wrong while submitting the form.

Request a Demo

Request a Demo

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Request a Demo