Attacks targeting these supply chains have opened a new perimeter of risk in information systems. Breaches can lead to intellectual property theft, tampering with source code, service disruption, and privilege escalation into more critical parts of the IT landscape. 

What are the new attack vectors in CI/CD pipelines, and how can they be contained? This article reviews real-world compromise scenarios and provides recommendations to defend against them. 

What risks for CI/CD pipelines? 

The 2020 SolarWinds breach is very often cited as CI/CD compromise, as it revealed the true scale of that such an attack can cause. After supposedly stealing FTP credentials left in plaintext in an old GitHub repository, attackers poisoned SolarWinds’ supply chain by inserting a C2 beacon into Orion, its network management software, before the signing process. 

This backdoor gave adversaries months of undetected access to the internal networks of U.S. government agencies and private companies. 

Incidents like this, along with more recent ones such as Log4Shell, Codecov, and XZ Utils, highlight not only the need for stronger CI/CD security but also for a more adaptive incident response. OWASP published a dedicated overview for CI/CD Security in their Top 10, mapping out the most common areas of risk. 

Figure 1 – Top 10 OWASP CICD-Sec 

Field insights @ Wavestone

Audits and penetration tests help identify vulnerabilities proactively before attackers can exploit them. By simulating real-world attacks, these assessments provide concrete visibility into how systems can be compromised. 

Our recent client engagements have led to clear findings: 

• In nearly all Cloud and CI/CD audits, vulnerabilities are always discovered in pipelines, often enabling full control of the pipeline, its artifacts, or even underlying infrastructure. 
• In CERT and Red Team interventions, CI/CD pipelines frequently act as accelerators in attack paths. 

Here are two examples observed in the field. 

Example 1: Full AWS compromise through CI/CD abuse 

In this first grey-box example, we compromised an entire AWS Cloud environment (600+ accounts) starting from standard DevOps accounts. 

Figure 2: Full AWS compromise through CI/CD abuse 

Attack path: 

• An attacker pushed malicious code into a GitLab repository, triggering a GitLab CI pipeline that deployed the code into a generic Kubernetes pod. 
• The code opened a reverse shell, giving the attacker remote access to the Kubernetes environment. 
• From there, the attacker exploited excessive privileges granted to the node’s service account (ability to patch tokens in the cluster) and replaced the admin node’s token. 
• On redeployment, the malicious pod lands on the former admin node, still holding admin rights. 
• The attacker escalated privileges and pivoted into AWS, compromising the entire Elastic Kubernetes Service (EKS) cluster and its resources. 

Example 2: Chained attacks across pipeline components 

Figure 3 -Summary of real chained attacks across pipeline components 

In another case (presented at DefCon & BSides 2022), we demonstrated how multiple components of a CI/CD pipeline can be chained together in compromise scenarios. [Video]. 

Recommendations to secure a CI/CD 

CI/CD pipelines have now become systemic components of information systems and can be leveraged to compromise an organization’s most critical resources. 

Our recommendations for securing the CI/CD chain can be grouped into three main themes: identity and access management (IAM), better pipeline design, and continuous monitoring. These align with the ANSSI DevSecOps guidance. 

Figure 4 – Three main recommendations to secure a CI/CD 

Identity and Access Management (IAM) 

Figure 5 – IAM recommendations 

Identity management 

Beyond the traditional rules for managing identity lifecycles, it is strongly recommended to systematically use Single Sign-On (SSO) combined with Multi-Factor Authentication (MFA). This significantly reduces the risk of intrusion into the CI/CD chain, by ensuring that any user accessing code repositories, signing commits, or performing other privileged actions is properly authenticated. 

Access control 

User and service account permissions must be strictly limited to what is necessary for their role within the CI/CD chain, always applying the principle of least privilege. This should be enforced through Role-Based Access Control (RBAC). For example, a developer working on a specific project generally should not have write access to the overall pipeline configuration. 

It is also advisable to segment projects using separate code repositories, and to ensure that the orchestrator account of one project does not hold excessive rights over the deployments of projects it is not associated with. 

Secrets management 

In CI/CD, “secrets” refer to sensitive data such as passwords, API keys, certificates, or access tokens. Since these secrets often enable privileged actions within pipelines, they must be retrieved in an automated and controlled manner. 

Vendors such as HashiCorp provide dedicated secret management solutions that make it possible to store sensitive data centrally, while ensuring encryption in transit and at rest. 

CI/CD pipeline design 

Figure 6 – Design recommendations 

Environment segmentation 

Segregation between users, applications, and infrastructure is essential to minimize the impact of a compromise. In line with ANSSI’s guidance, actions performed by the production CI/CD chain should be treated as administrative actions, and the number of users authorized to access it should be kept to an absolute minimum. Furthermore, communication between environments must be protected with end-to-end encryption. 

Integration of third-party tools 

As the SolarWinds attack demonstrated, many supply-chain compromises originate from a third-party component integrated into a CI/CD pipeline. These tools are indispensable for supply-chain operation: they may be as small as a development add-on, or as central as a version control system or orchestrator. 

Because these tools are often granted high privileges—access to sensitive resources or the ability to perform critical actions within the pipeline—a vulnerability that is left unpatched can be catastrophic. In many cases, the ability to remediate will depend on the vendor, limiting the organization’s own control. A strict governance framework and a Third-Party Cyber Risk Management (TCPCRM) process for third-party tools is therefore necessary. 

Artifact management 

To avoid the risk of distributing malicious artifacts, it is recommended to sign artifacts as early as possible in the pipeline, and to verify those signatures at deployment time to guarantee their integrity. Similarly, regular Software Composition Analysis (SCA) should be performed to prevent the introduction of malicious libraries. 

Monitoring and supervision 

Figure 7 – Monitoring recommendations 

Logging and detection 

Maintaining a high level of visibility and control over all pipeline components is critical for easier maintenance and faster response to attacks. 

A tailored logging strategy should be implemented: logs must contain only the data needed to ensure traceability and accountability in the event of an incident, should be stored securely, and must not contain secrets in plaintext. Logs should be shared effectively with the organization’s Security Information and Event Management (SIEM) system. 

Regular audits and penetration tests are also required to reassess the security posture and identify potential new compromise paths within the CI/CD pipeline. 

Incident response 

Finally, CI/CD pipelines must be included in incident response plans just like any other perimeter of the information system. This means ensuring that source code and configurations are backed up, and that business continuity plans exist in case of a tool failure. 

In conclusion 

CI/CD pipelines have become a genuine cornerstone of modern information systems. They are now systemic components, indispensable for developing and deploying applications. Yet their critical role within IT also makes it necessary to implement appropriate security measures so that they do not themselves become attack vectors. 

Figure 8 – Some systemic CI/CD components 

Beyond the recommendations detailed in this article, further preventive measures can be implemented in the form of hardening guides tailored to specific tools within the pipeline. In addition, adopting a robust training strategy for users, together with structured change management, is essential to ensure the success of these transformations. 

Thanks to Jeanne GRENIER for her valuable contribution to the writing of this article.

Cet article CI/CD: the new cornerstone of the Information system?  est apparu en premier sur RiskInsight.

This is where Application Security Posture Management (ASPM) steps in. Managing numerous applications and their associated security tools while maintaining comprehensive visibility is increasingly challenging. ASPM provides a logical response to the growing complexity of CI/CD toolchains, aiming to unify AppSec management under a single platform. It enables security teams to clearly view and assess the security posture of all their application perimeters. 

The goal of this article is to briefly go over ASPM’s capabilities, and to confirm whether it is simply another take on vulnerability management or if the paradigm has shifted towards a new unique type of security tool. We will also debunk key factors that businesses should consider when selecting the right ASPM solution. 

What is ASPM? 

ASPM, or Application Security Posture Management, is one of the latest buzzwords in AppSec. Popularized after Gartner’s May 2023 insight document, ASPM refers to technology that consolidates all application security tools into a single interface. Over the past year, several startups and established AppSec vendors have rebranded or launched proprietary solutions to acquire part of this emerging market. 

The definition provided by Gartner is as follows: “Application security posture management (ASPM) offerings continuously manage application risks through detection, correlation, and prioritization of security issues from across the software life cycle, from development to deployment. They act as a management and orchestration layer for security tools, enabling controls and the enforcement of security policies.” 

Fig 1 – Overview of ASPM features 

The primary value of ASPM lies in delivering scalable security from code-to-cloud. ASPM enhances visibility at every stage by reducing false positives, minimizing alert fatigue, and providing a single source of truth for vulnerability ownership. This is key for organizations overwhelmed by thousands of alerts and struggling to allocate resources for remediation effectively. 

How is ASPM unique compared to existing solutions? 

Traditional vulnerability management tools aggregate and prioritize security issues detected by scanners. However, they are not exclusive to application security and often span broader IT perimeters in the information system. 

If you are familiar with the topic, Application Security Orchestration & Correlation (ASOC) originally marked a shift by focusing specifically on managing application security issues. ASOC offered DevSecOps teams an interface to orchestrate tools and streamline remediation workflows. 

ASPM on the other hand can be seen as an evolution of ASOC, extending its scope from simple code security to code-to-cloud. This includes analyzing not just application code but also the infrastructure and resources used in development and deployment. For example, ASPM can assess configurations, container images, and Infrastructure-as-Code (IaC) modules like Terraform scripts. 

Other key differences between ASPM and ASOC include: 

1. Enhanced Prioritization: ASPM prioritizes business-critical risks over simple CVSS-based issues, often leveraging advanced algorithms for triaging. 
2. Compliance Support: ASPM allows organizations to triage vulnerabilities based on frameworks such as OWASP, ISO, and SOC2, helping organizations achieve compliance. 
3. Policy-as-Code: ASPM enables organizations to define policies, such as blocking deployments if risk scores exceed thresholds or if code reviews are incomplete. 

Decisive factors in choosing a provider  

If used right, ASPM can effectively help teams optimize their workflows and remediate security issues faster. Nevertheless, even if all ASPM providers have their own strengths and uniqueness, selecting the right solution is essential since not all of them will suit every organization.  

Fig 2 – Non-exhaustive panel of ASPM providers 

Each context brings its own unique decisive factors when choosing the right ASPM, some of which include: 

• Can this solution integrate the tools I already have? How close to a plug-and-play experience will it be? 
• How far can I integrate this ASPM in my CI/CD? How far can it automate remediation workflows? 
• Who are the targeted end users? (Security team, Security champion, Devs & Ops) 
• Is the ASPM leveraging a custom algorithm for prioritization or rather CVSS, EPSS? 
• Is the interface aesthetically pleasing and easy to use? Can I customize it? 
• How does the provider handle my data? 
• Is the security of the ASPM itself up to my standards? Does it support SSO, MFA, RBAC? 
• What is the support level provided by the editor? 
• Are the proposed subscription plans adapted to my organization’s needs? 
• What is concretely meant by the advertised use of Artificial Intelligence in the solution? 

Some things to look out for 

DevSecOps maturity 

ASPM can therefore be defined as a useful yet somewhat “niche” solution for application security. While it can function as a relatively effective plug-and-play tool, ASPM still requires integration work and fine-tuning by security teams to maximize its potential. Organizations that lack a robust security stack or are still in the early stages of building a DevSecOps pipeline may benefit less from ASPM. For such organizations, focusing on foundational tools and processes before adopting ASPM might be a more practical approach. 

Managing false positives and false negatives 

One of ASPM’s promises is to reduce false positives, which is a common benefit of vulnerability management. In practice, however, while noise is minimized, it is rarely entirely eliminated. Security teams must still manually triage and address vulnerabilities that the system cannot confidently classify as false positives. 

Another critical concern is the potential for false negatives. Some vendors claim their tools “reduce vulnerabilities by 99%”, though, unless the risk-scoring algorithms are fully transparent, there is a risk that genuine security issues might be overlooked. When algorithms classify certain vulnerabilities as insignificant without proper justification, this creates blind spots that could expose the organization to unaddressed risks. 

Accordance with teams’ needs  

Before committing to ASPM, it is necessary to ensure that the solution fits the organization’s specific requirements. Running a proof-of-concept (PoC) on a small scale— testing the platform with diverse teams operating under different dynamics— can provide valuable insights into its adaptability and usability. 
Most ASPM solutions are offered as SaaS platforms, simplifying deployment for PoC and making it easier to evaluate the tool without significant initial investment. 

Security 

Given that ASPM often has access to sensitive data, such as source code and real configurations, organizations must thoroughly verify that the solution adheres to their security standards. Failure to do so could turn ASPM into a single point of failure within the security stack. 

An alternate definition of ASPM? 

Vulnerability managers and ASOC in their essence do not aim to incorporate built-in scanners, but simply to aggregate findings from other tools. Similarly, the core value of ASPM as it was defined by Gartner is to manage risk in Code-to-Cloud settings, without meddling in the scanning part, which is left to AppSec and CSPM tools. 

However, almost two years after Gartner’s study was released, ASPM has steered towards a direction that somewhat diverges from their initial vision. ASPM providers have started integrating proprietary scanners inside of their solutions so that their customers would not have to acquire third-party ones. A great article from James Berthoty rightfully argues that since Gartner’s definition of ASPM can simply be deemed an evolution of ASOC, there’s no reason to call it anything other than ASOC. 

Arguably, the only legitimate reason to evolve from ASOC to ASPM would be a new type of tool aiming to conquer a need of the AppSec market which has not been fulfilled yet: an all-in-one platform for application security. By simply connecting your source code and your environments, this platform would scan everything, aggregate the findings, and simply output the most critical issues and how to remediate them. This could be especially relevant for organizations with no prior security stack looking for a full AppSec solution, whereas those who want to keep their current toolchain may opt for an aggregator version of ASPM instead. 

Fig 3 – Defining the ideal ASPM 

To conclude 

Gartner originally predicted that by 2026, over 40% of organizations developing proprietary applications would use ASPM to manage risks in their applications. While this prediction might be slightly ambitious, the need for better application security tooling and a centralized security management platform is also rising quickly.  

To realize its full potential, ASPM must be part of a broader DevSecOps strategy. Organizations need to establish the right processes, governance, and CI/CD foundations to fully benefit from it.  

Cet article From Vulnerability Management to ASPM: Evolution or Revolution?  est apparu en premier sur RiskInsight.