Secure your CI/CD pipelines from supply chain attacks with Sumo Logic’s Cloud SIEM rules

Supply chain attacks, particularly those targeting continuous integration/continuous delivery (CI/CD) pipelines, are on the rise. It’s easy to think of these attacks as something that only happens to others, but the reality is that your organization is part of the supply chain too. Whether your company develops software for internal use, offers it as part of a service to your customers, or sells it as a product, you’re exposed.

If your organization uses CI/CD tools such as Azure DevOps or GitHub Enterprise, attackers could exploit these systems to compromise your code or use the infrastructure to gain access to your network. Securing your CI/CD pipelines isn’t optional. It’s essential. That means continuously auditing usage, collecting audit logs in your SIEM solution, and actively monitoring logs for malicious activity to prevent breaches or security incidents.

Sumo Logic’s out-of-the-box Cloud SIEM rules for Azure DevOps and GitHub simplify this process by cutting through the noise, detecting threats, and giving you greater control and visibility of your software supply chain.

Supply chain attacks defined

Supply chain attacks have made big news in recent years. Notable examples include:

• The devastating SolarWinds attack, which impacted nearly 18,000 victim organizations.

• The compromise of financial software X_TRADER led to attacks against communications, financial, and critical infrastructure companies.

• The Kaseya compromise, where attackers compromised their management software to perform ransomware attacks on approximately 1,500 of their customers.

Supply chain attacks come in many forms. They can range from stealing a service provider’s credentials (such as the 2013 Target breach via their HVAC contractor) to exploiting vulnerabilities found in open-source code used in many vendors’ software (such as log4j).

Read on to learn about attacks that occur during software development and distribution. In these attacks, malicious code is executed into trusted software, potentially weaponizing it to cause harm.

Ultimately, supply chain attacks exploit trust. Attackers take advantage of users’ implicit trust that the companies that provide software and services have no malicious intent and are diligent in their security practices.

How attackers exploit CI/CD pipelines for supply chain attacks

Consider the high-profile attacks listed above and how the attacker achieved their objectives. In all of these cases, the attacker hijacked a phase of the software build or software distribution process to introduce malicious code. Let’s take a closer look at the methods attackers used to breach these systems:

• SolarWinds: “[The attacker] breached one of Orion's build servers and implanted a backdoor into one of the update modules. This compromised update, digitally signed, was distributed to approximately 18,000 SolarWinds customers, including Fortune 500 companies, and made available through their website.”

• 3CX: (The supply chain attack enabled by the X_TRADER attack): “Eventually, the attacker was able to compromise both the Windows and macOS build environments. On the Windows build environment, the attacker deployed a TAXHAUL launcher and COLDCAT downloader that persisted by performing DLL search order hijacking through the IKEEXT service and ran with LocalSystem privileges. The macOS build server was compromised with POOLRAT backdoor using Launch Daemons as a persistence mechanism.”

• Kaseya: “Using an exploit of Kaseya’s VSA remote management service, the REvil actors launched a malicious update package that targeted customers of managed service providers and enterprise users of the on-site version of Kaseya’s VSA remote monitoring and management platform.”

The Sumo Logic Azure DevOps and GitHub rules

The Sumo Logic Threat Labs team has released two sets of rules within the Sumo Logic Cloud SIEM to help monitor and detect attacker activity in your CI/CD environment:

• GitHub rules: A series of rules designed to detect suspicious activity in GitHub, released on December 6, 2024.

• Azure DevOps rules: A set of rules based on Microsoft’s Sentinel rules for Azure DevOps, along with tuning guidance provided by IBM’s X-Force Red in their excellent paper “Hiding in the Clouds: Abusing Azure DevOps Services to Bypass Microsoft Sentinel Analytic Rules.” These rules were released on March 13, 2025.

How to get started with Sumo Logic’s Azure DevOps and GitHub rules

If you are a Sumo Logic Cloud SIEM customer, your environment already has Azure DevOps and GitHub rules enabled. To take advantage of these rules, ensure you’re collecting logs from your CI/CD platform. Here’s a quick walkthrough on how to perform log collection.

Azure DevOps log collection

To collect Azure DevOps logs:

1. Enable auditing in your Azure DevOps organization.

2. Configure the audit logs to be streamed to an Azure Event Hub.

3. Collect the logs from the Event Hub using a Sumo Logic Hosted Collector.

For detailed instructions, check out Microsoft’s documentation on enabling auditing in your Azure DevOps organization and configuring the audit logs to stream to an Azure Event Hub. Also, see Sumo Logic’s “Azure Event Hubs Source” help topic for more details on collecting logs from Azure Event Hubs. Make sure that “Forward to Cloud SIEM” is enabled in the log source you create.

GitHub log collection

Note: The GitHub rules were developed specifically for GitHub Enterprise Audit Logs.

To collect GitHub logs:

1. Stream GitHub logs to an AWS S3 bucket.

2. Collect the GitHub logs from S3 via a Sumo Logic Hosted Collector.

For setup, follow GitHub’s "Setting up Streaming to Amazon S3” topic to configure log streaming to S3. Then, use Sumo Logic’s “Amazon S3 Source” help topic to configure log collection from the S3 bucket. Be sure to add the following fields when setting up the log source:

Configuration example - GitHub log collection via Amazon S3 log source

Attacker techniques that Sumo Logic’s Cloud SIEM rules detect

Sumo Logic’s Cloud SIEM rules detect various attacker techniques in your CI/CD environment. Below are some key attacker tactics detected by the Azure DevOps and GitHub rules.

Technique: Pull request review bypass

Detecting rules:

• Azure DevOps - First seen pull request policy bypassed

• GitHub - Pull request review requirement removed

CI/CD pipelines are built for speed, enabling developers to push code updates to production multiple times per day. Although this rapid release cadence benefits an organization and its customers, it increases the risk of a developer unilaterally pushing buggy or malicious code into production.

One way to mitigate this risk is to do a peer review, a process in which pull requests must be approved before proceeding to the build/release pipeline.

According to the OWASP Top 10 CI/CD Security Risks, bypassing the review process is the top risk in CI/CD. A real-world example of this risk occurred in March 2021, when unapproved changes were made to the PHP code base.

Bypassing review can be warranted, and Azure DevOps provides the option to bypass pull request policies via the “bypass policy” setting. Your organization may have valid reasons for bypassing pull request policies, if only temporarily. If a bypass policy is allowed, you’ll want to monitor for potential misuse.

The Azure DevOps rule “First seen pull request policy bypassed” alerts the SOC analyst to a user bypassing a pull request when they haven’t been observed doing so in the last 90 days. If the rule triggers, the SOC analyst should determine whether the pull request bypass was expected and investigate the user who performed the pull request bypass for indications of account compromise or other insider threat activity.

First seen pull request policy bypassed rule and log sample

The GitHub rule “PR review requirement removed” also monitors for bypassing pull request review, but it does so by completely removing the review requirement from the repository.

PR review requirement removed rule and log sample

Technique: Membership changes to privileged groups

Detection rules:

• Azure DevOps - Change made to the administrator group

• GitHub - Administrator added or invited

In May 2019, the Stack Overflow network was compromised by an attacker who “gained moderator and developer level access across all of the sites in the Stack Exchange Network.” The attacker exfiltrated source code and personally identifiable information (PII) of 184 Stack Overflow users as a result of this attack.

Any event in which a user obtains administrative privileges is noteworthy, given the impact that the user can have. OWASP ranks inadequate identity and access management as the second greatest risk to CI/CD pipelines. This risk covers a variety of ways in which identity mismanagement can leave the CI/CD pipeline open to compromise, including non-adherence to the principle of least privilege.

The Azure DevOps rule “Changes made to administrator group” notifies SOC analysts when a user is added to several privileged groups in Azure DevOps, such as Project Administrators, Project Collection Administrators, Project Collection Service Accounts, Build Administrators, and Project Collection Build Administrators.

If this rule triggers, the SOC analyst should determine whether the group modification was an approved change, such as by checking for a corresponding change control ticket if CI/CD is within the scope of change control, and investigate the user who made the modification for indications of account compromise.

Change made to administrator group rule and log sample

Similarly, as the name implies, the GitHub rule “Administrator added or invited” detects when a new administrator is added or invited.

Administrator added or invited rule and log sample

Technique: Malicious tool integration

Detection rules:

• Azure DevOps - First seen - New extension installed

• GitHub - First seen application interacting with API

There’s a rich ecosystem of tools that can be integrated into your CI/CD environment to add functionality such as code checking, resource management, and secrets substitution. Unfortunately, these tools and services are also an attack vector.

In July 2020, the credentials for the DeepSource GitHub application, which provides functionality such as static analysis, SAST, code coverage, and IaC analysis, were compromised and were used to compromise the credentials of the app’s users.

The Azure DevOps platform includes an Extensions Marketplace. As demonstrated by the DeepSource example, installing and using extensions runs the risk of introducing malicious code from the extension itself or from attackers obtaining a foothold in your DevOps environment via the extension. OWASP rates this risk, which falls into the category of “ungoverned usage of 3rd party services,” as the eighth most prevalent risk.

The Azure DevOps rule “New extension installed” will trigger when a new extension (against a 90-day baseline) has been installed into the Azure DevOps organization. If this rule is triggered, the SOC analyst should investigate whether this is a known change (via change control tickets, for example) and whether the extension is approved for use in the organization.

New extension seen rule and log sample

The GitHub rule “First seen application interacting with API” monitors applications using the GitHub API that haven’t been observed doing so in the last 90 days. This detection casts a wider net than the “New extension seen” detection in that it triggers any unknown applications interacting with the API, not just extensions.

First seen application interacting with API rule and log sample

Logging your CI/CD environment is critical to monitoring its security. OWASP agrees and ranks “Insufficient Logging and Visibility” as risk #10, citing that "insufficient logging and visibility risks allow an adversary to carry out malicious activities within the CI/CD environment without being detected during any phase of the attack kill chain, including identifying the attacker’s techniques, tactics, and procedures (TTPs) as part of any post-incident investigation."

Secure your CI/CD environment with Sumo Logic

Supply chain attacks are a growing threat, and your CI/CD environment is a prime target. By proactively monitoring your CI/CD ecosystem with Sumo Logic’s Cloud SIEM rules, you can detect and respond to suspicious activity before it leads to a full-blown breach.

To learn more about Sumo Logic Cloud SIEM, check out the product or click through an interactive demo.