CI/CD audits conducted in 2025 and 2026 revealed that credentials leaked in repositories, misconfigured runners, insecure artifact stores, and overly permissive cloud roles are all vectors attackers can chain to gain persistent, high-privilege access across the entire infrastructure.

A high-level overview of DevOps tooling is illustrated below:

A compromise at any stage of the pipeline can provide a path toward more sensitive systems.

This article walks through a representative CI/CD attack kill chain based on observed real-world patterns, highlighting the most commonly exploited vectors and the key hardening measures to reduce the attack surface at every stage of the pipeline, from source code to production deployment.

The Kill Chain: from reconnaissance to persistence

Reconnaissance and Initial Access

The kill chain typically begins with a phishing targeting developers to harvest credentials and MFA codes, though MFA itself can be bypassed through token hijacking or session theft.

It should be noted that credential compromise alone is not always sufficient to directly access sensitive administrative portals. Security controls protecting Microsoft 365 administrative interfaces have been strengthened through the implementation of MFA and, where applicable, Conditional Access policies, limiting the impact of phishing on highly privileged access.

However, in modern enterprise environments where most business applications rely on Single Sign-On (SSO), the compromise of a Microsoft session (e.g., through session cookie theft) can provide attackers with access to a wide range of interconnected services, including code repositories and CI/CD platforms. Attackers typically use this initial foothold to identify development environments and establish persistence through mechanisms such as Personal Access Tokens (PATs).

A common but often overlooked risk arises when user accounts are disabled at the identity provider level (e.g., Entra ID) but not fully deprovisioned within repository platforms. In such cases, previously issued PATs may remain valid, allowing attackers to retain repository access despite account revocation.

Additional entry points include the exploitation of known CVEs and poor credential hygiene. Many major vulnerabilities in DevOps tools are regularly discovered, highlighting the need for continuous vulnerability management. Exploiting a critical vulnerability can directly provide privileged access to a tool in the chain.

Examples include:

• CVE-2024-23897 (Jenkins), which allows unauthenticated attackers to read arbitrary files on the Jenkins controller file system, leading to exposure of sensitive secrets,
• CVE-2023-7028 (GitLab), in which user account password reset emails could be delivered to an unverified email address,
• CVE-2023-36561 (Azure DevOps Server), an elevation of privilege vulnerability allowing attackers to gain unauthorized access to functionalities within Azure DevOps Server, with potential impact on pipelines, secrets, and project-level resources.

REMEDIATION – Strengthen Access Controls for Source Code Repository

To mitigate initial access risks, organizations should implement controls to prevent unauthorized access, detect persistence, and enforce strong identity governance.

Enforce confidential access policies and network exposure

• Avoid the use of generic or shared accounts,
• Use dedicated developer identities separated from standard productivity (email and office) accounts to reduce exposure to phishing attacks and limit the impact of credential compromise in CI/CD environments.
• Enforce phishing-resistant MFA mechanisms (FIDO2 keys, certificate, etc.),
• Implement Conditional Access policies to restrict access based on contextual factors such as network location and device compliance.

Implement mechanisms to detect persistence attempts

• Implement monitoring mechanisms to detect suspicious creation or usage of PATs in GitLab, anomalous activities such as deployments occurring at unusual times, etc.
• Monitor the addition of new authentication methods in Entra ID, as a potential sign of compromise, particularly passwordless ones, after a phishing event.

Recertify all accesses periodically and remediate unused accounts

• Disable or remove unused or inactive accounts,
• Revoke access for offboarded employees across all systems,
• Conduct periodic access reviews, at least every six months for high-risk users.

Code Repository and Pipeline Compromise

Source code repositories are often directly integrated with CI/CD pipelines, meaning that changes to the codebase can automatically trigger build and deployment processes. As a result, compromising a developer account can influence how applications are built and deployed.

To reduce the risk of unauthorized changes reaching production, organizations typically protect production branches (e.g., main or master) through pull requests, approvals, and automated validation checks. In contrast, development branches are generally less strictly controlled to support faster development and testing.

In the observed scenario, the attacker targets the development branch and modifies the pipeline configuration file (gitlab-ci.yml), injecting a malicious command (aimed at establishing remote access) into an existing job. When the pipeline is executed, this command runs on the CI/CD runner, allowing the attacker to gain remote access to it.

As part of the compromised CI/CD environment credentials, the attacker gains access to a Nexus token, which is an artifact management system, used to store and distribute trusted build artifacts consumed by downstream pipelines.

REMEDIATION – Harden Code Repository Security Controls

Securing the code repository is essential to prevent attackers from abusing CI/CD pipelines after initial access, as repositories directly control how code is built and deployed.

Harden code repository to limit pipeline triggers

• Configure protected branches on the branches used for deployment,
• Set up multi-level approval workflows on merge requests that trigger pipelines and disable self-approval,
• Use code ownership to assign and require approval from designated owners on sensitive files (e.g. CI/CD job configuration).

Limit project visibility and permissions

• Limit writing permissions to only those who require them for their role,
• Restrict project visibility based on the need-to-know principle, using internal or private (preferred) visibility.

Establish proper secret management hygiene

• Configure scoped CI/CD secrets the project level and prefer ephemeral credentials whenever possible,
• Detect secrets in clear text as early as possible (at commit time or before code is pushed) and revoke immediately if exposed,
• Conduct periodic reviews (e.g., internal audits or red team exercises) across platforms such as Git repositories, Jira, or Confluence to help identify previously undetected leaks.

REMEDIATION – Strengthen Self-Hosted Runner Security Controls

Runners are critical components of CI/CD pipelines, as they execute code and handle sensitive data. If compromised, they can be used to move laterally, access secrets, or take control of the environment.

Restrict network exposure and execution scope

• Restrict runner network traffic to only what is required for pipeline execution, and enforce network controls such as proxies and segmentation to prevent unrestricted internet access and limit lateral movement within internal networks.
• Restrict pipeline triggers from untrusted or personal repositories.

Treat runners as sensitive systems

• Treat runners as critical servers (regular OS patching and hardening),
• Deploy Endpoint Detection and Response (EDR) solutions for process monitoring, including within containerized environments.

Use dedicated and ephemeral runners

• Prefer dedicated runners per project or environment. Sharing runners across multiple contexts increases the risk of cross-project contamination and privilege escalation,
• Use ephemeral / autoscaling runners that are destroyed after each job,
• Ensure VM-based runners are also ephemeral and isolated to ensure no residual data or access persists between executions. In addition, rely only on hardened and trusted base images (e.g. golden images for VM-based runners and approved container images), to prevent execution in compromised or unverified environments.

Secure container-based runners

• Allow only approved and trusted images in pipeline executions to prevent the introduction of malicious code through compromised or unverified images,
• Apply least privilege in container runtime environments,
• Avoid privileged mode and drop unnecessary Linux capabilities,
• Use secure build engines (BuildKit / Buildah) when Docker-in-Docker is required

Harden Cloud-based runners

• When using cloud-managed runners, enforce isolation and identity scoping, restrict metadata access to prevent credential exposure from underlying infrastructure, and ensure CI/CD roles are governed by strict least-privilege IAM policies to avoid excessive permissions.

Artifact Poisoning and Dependency Attacks

In software delivery environments, artifact management systems store and distribute outputs generated by CI/CD pipelines. These outputs, known as artifacts, represent the packaged results of the build process, such as compiled binaries, application packages, or deployment images.

Artifacts are stored centrally to ensure versioning, traceability, and reuse across multiple pipelines. In addition to application-specific outputs, these repositories often also host shared components such as golden images, reusable libraries, or common runtime dependencies. Because they originate from trusted build processes, artifacts are typically assumed to be safe and are widely consumed by downstream pipelines without additional validation.

In the observed scenario, the attacker uses previously obtained credentials to authenticate to the artifact repository (Nexus in this example) with excessive permissions (read/write across multiple categories, rather than being limited to a single application scope), and gains access to both production-grade and shared artifacts.

Among these, the attacker identifies a legitimate Terraform binary used within the infrastructure deployment process (referred to as the tofu binary), which is commonly trusted and consumed by downstream CI/CD pipelines to provision and manage cloud resources.

The attacker downloads this artifact locally and modifies its contents by injecting malicious logic while preserving its original functionality, and embeds hidden behavior designed to interact with AWS Identity and Access Management (IAM) and AWS Security Token Service (STS) services to retrieve credentials.

The modified binary is then reuploaded to Nexus, replacing the legitimate version with a poisoned artifact.

From this point onward, any CI/CD pipeline consuming the artifact automatically retrieves the compromised binary as part of its dependency resolution, as it’s still considered trusted.

Upon execution, the poisoned binary activates the embedded malicious payload, which is designated to retrieve the AWS access token used by the Terraform execution context and send it to the attacker-controlled server for exfiltration. It then generates an obfuscated output encoded in Base32. Decoding allows reconstruction of a JSON object containing AWS credentials (AccessKeyId, SecretAccessKey, and SessionToken).

The attacker configures these credentials locally and uses AWS STS (GetCallerIdentity API call) to confirm identity impersonation of the CI/CD runner. 

This illustration shows the attack chain: artifact compromise, injection of malicious logic, propagation through CI/CD pipelines, and eventual AWS credential theft leading environment compromise.

As a result, the attacker gains unauthorized access to AWS resources under the guise of a legitimate identity.

REMEDIATION – Improve Artifactory Access Management Controls

Artifact repositories such as Nexus are key CI/CD components used to store and distribute build dependencies and artifacts. They are high-value targets for supply chain attacks.

Security requires strong access control, dependency governance, and continuous integrity monitoring.

Harden the artifact repository platform

• Allow wide read on repository only at two conditions: from needed service (CICD) and if password management in dependency exist,
• Highly restrict writing permission,
• Change default

Perform Software Composition Analysis (SCA)

• Apply Software Composition Analysis to both internal dependencies (stored in local repositories) and external ones (retrieved from remote or proxy repositories) to detect known vulnerabilities and outdated components.

Restrict artifact sources

• Maintain a whitelist of trusted repositories to ensure only approved sources are used,
• Enforce repository-level controls to exclude unapproved or vulnerable versions, for example in Nexus, or through exclusion rules in JFrog Artifactory,
• Prevent CI/CD pipelines from accessing untrusted external sources by enforcing strict repository boundaries.

Cloud Compromise via CI/CD Workload Abuse

In cloud environments, CI/CD runners are typically assigned privileged IAM roles to perform deployment operations, including creating, modifying, and deleting infrastructure resources. These roles often include broad permissions such as AdministratorAccess or overly permissive custom policies, enabling the runner to interact with a wide range of AWS services including compute, storage, and identity management.

When a CI/CD runner is compromised, an attacker can directly abuse these privileges without requiring further escalation. This can lead to immediate access to sensitive resources such as S3 buckets or RDS databases, enabling data exfiltration. The attacker may also leverage IAM permissions to assume additional roles across other AWS accounts or projects, facilitating lateral movement within the organization. In addition, access to compute-related services can be abused to deploy, modify, or persist malicious workloads, ultimately resulting in a full compromise of the cloud environment.

From developer compromise to Cloud takeover: full CI/CD attack path overview

The CI/CD attack chain starts with the initial compromise of a developer and ends with the full takeover of the cloud environment.

The following illustration highlights key detection and monitoring opportunities across the CI/CD ecosystem. It shows how security telemetry can be collected and correlated throughout the different stages of the CI/CD attack chain, from development activities to CI/CD runners, artifact repositories, and cloud IAM operations.

Overall, although CI/CD pipelines significantly expand the attack surface, they also provide multiple strategic interception points where centralized logging and security monitoring can enable early detection and response to malicious activity.

In conclusion, to achieve a secure CI/CD pipeline, security must be considered end-to-end, from developers’ environments to production systems.

Developers are the first link in the chain, and securing their accounts is essential. This should be supported by good practices such as secure secret management and regular security awareness.

It’s also important to ensure proper isolation between environments and to enforce strict least privilege for both users and service accounts.

Security issues cannot be fixed by small patches if the overall pipeline design is weak.

Finally, deployment use cases should be clearly defined from the start, as they directly drive the architecture and IAM design choices.

Beyond these technical measures, CI/CD security must be continuously assessed through regular technical audits as well as organizational reviews of the development lifecycle to ensure risks remain under control as the environment evolves.

For a broader perspective and higher-level recommendations on positioning CI/CD as a cornerstone of the information system, see the RiskInsight article: “CI/CD: the new cornerstone of the information system”.

Cet article CI/CD Security: Supply chain attack from a compromised developer 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.

How to ensure the security of your applications despite outsourcing their development?

Integrating security into projects is an important process for companies to define and integrate security aspects into products as early as possible. This avoids increasing the cost of remediation if it has not been planned and is implemented at the end of the project.

In the context of developments, Agile Security and DevSecOps define the processes and tools to be put in place to integrate security as early as possible, as presented in our previous article giving examples.

These methods are often defined on internal developments. However, it is often the case that companies call on external service providers to develop a particular application or functionality. In this case, it is important to ensure that these providers follow rigorous security practices and that they integrate security into their development processes to the same standards as the requester. This leads to the following question:

External developments: how to maintain confidence in externally developed code?  

In the remainder of this article, external code is defined as all code elements that have not been developed through an internalised CI/CD chain. For example, a freelance developer using the internal CI/CD chain or an enterprise workstation is not considered external code.

In addition, we will consider two models of application delivery depending on the development model used by the provider:

• delivery of the source code itself
• delivery of the executable, i.e. the already precompiled code

It is important to note that these two application delivery models have different implications in terms of cyber security and DevSecOps.

Code delivery

In the case of code delivery, external providers hand over the code they have written, usually in the form of source files (e.g. .java files for Java code), to the company. The company can then audit, compile and deploy the code on its own servers.

Code delivery has several advantages. The first advantage is flexibility: by delivering the source code, the company can easily make changes and customisations to the code. It can also integrate the code into its existing development and deployment environment (CI/CD) containing all the pre-configured security tools.

The company then does not have to place its trust in the security of the provider’s CI chain over which it has no control. In addition, the company with access to the source code can also audit it and thus verify that it is secure. These audits tend to be more comprehensive as the auditor has access to much more detail about the operation of the code and can perform both static and dynamic analysis of the code.

On the other hand, code delivery has some disadvantages. The company must have the skills to adapt the build and deployment stages to the production context. If these skills are not available in-house, this can lead to additional costs.  

Here are some good practices to maximise confidence in the delivered code:

• Share as early as possible (contract, kick-off meeting) the expected requirements on security in development, software versions, internal tooling used for deployment, confidentiality of source code, etc. Some clients require external developers to have a certain level of certification or training (for example, a level of training on Secure Code Warrior, in a certain programming language).
• Define and contractualise commitments on the remediation processes for identified vulnerabilities after code delivery and the associated monitoring (monitoring tools, SLAs, etc.)
• Implement a hash or signature type control on the code sent to ensure its integrity and define the methods for secure transfer of the source code with the service provider
• Integrate the code received into the existing CI/CD chain, including the Infrastructure as Code (IaC) files
• Carry out the functional security tests initially defined during the threat modelling: Evil User Stories and Security Stories

Some organisations may be faced with a situation where the notion of external developers corresponds to developers from other entities within the same group. These entities may have their own CI chains but depend on the CD or CI/CD chain of the central production team.

In these cases, an interconnection of the different CI chains to the central CI/CD chain can be considered. This solution allows the different teams to develop with the tools that best suit them.

The level of security provided by the project CI/CD chain is ideally equivalent to that of production but this is not necessarily the case. The production CI/CD chain controls the code to be deployed.

However, security control is often carried out too late in the development process. To ensure effective security in developments, it is crucial to ensure that security is integrated from the beginning of the development cycle (shift-left). To address this, it is recommended to provide self-service security tools for project teams to identify vulnerabilities early in their development using the appropriate target tools.

Otherwise, the security tools in the production CI/CD chain will ensure compliance with the group’s rules without slowing down the production release if automated security controls have been put in place within the project chain.

This solution also allows production to ensure the use of images (systems, docker, etc.) or artefacts (libraries) validated by the company.

These interconnections between the different pipelines can, for example, clone the branch to be deployed by the product team in order to push them into the CD chain. However, the production teams must have the appropriate rights. Technically, the model for managing the rights granted (ideally temporarily) must meet both the need to facilitate execution and the need for rights provisioning (manual vs. automatic), while limiting access to all branches or projects in order to respect the principle of least privilege.

Most of the good practices mentioned above also apply to reduce the time to production.

Although the methods described above appear to be the most effective for gaining control over applications developed by third parties, companies sometimes find themselves receiving executables without access to the source code. This may be due to licensing restrictions, for example. In this case, some of the good practices outlined above do not apply, and it is necessary to rethink how to integrate changes into production so as not to neglect certain security aspects.

Executable delivery

In the case of executable delivery, external providers hand over an executable file (e.g., an .exe file for Windows servers) that can be directly executed by the company without compilation. This delivery method is often used for commercial software that still requires some configuration adjustments.

In this context, the integration in the deployment chain is much more limited and only a few classical CD steps can be performed without the security steps of the CI chain being verified:

• Performing an artefact scan
• Performing a DAST scan to detect the most common vulnerabilities
• Performing penetration tests

Reports from the security tools of the development provider’s chain can also be requested. This must be included in the service contract, along with the security requirements for the level of security of the code.

Finally, a signature of the code to ensure its integrity is necessary at the time of the exchange and the executable. For this purpose, it is better to use signatures via certificates rather than hash prints, since the latter make it possible to verify the origin (non-repudiation) in addition to the integrity of the executable.

In conclusion, it is important for companies to ensure the quality and security of the code delivered by external providers, especially when the latter are developing code on external CI chains. There are several ways to convince yourself of the security of the delivered code:

• Clear and precise contractual clauses can help define the expectations and responsibilities of each party with regard to the quality and security of the code.
• Sharing specifications and security expectations with external providers can also help ensure that the delivered code meets the company’s requirements.
• Integration with internal development chain tools can facilitate verification of code quality and security, as well as the implementation of automated testing. These integrations raise both technical and process challenges that must be anticipated to facilitate the deployment of external developments.

By implementing these different approaches, companies can increase their confidence in the code delivered by external providers and ensure the security of their application.

Cet article Stay in control of your external developments est apparu en premier sur RiskInsight.