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.

However, setting up a relevant and effective CI/CD pipeline for each project context can be complex. Technologies vary, security requirements can differ, and target environments are not always identical. Given the ambitions and challenges posed by creating a unified CI/CD pipeline, it may not always be prudent to leverage IaaS or on-premise services, which also require infrastructure team investments. Cloud (PaaS) solutions offer a good middle ground between customizing the CI/CD pipeline and ease of implementation. Cloud solutions also allow for on-demand resource provisioning to better adapt to business needs.

There are numerous cloud-based CI/CD solutions that can potentially meet both security and efficiency requirements for the development pipeline. In this article, we aim to present our perspective on Amazon Web Services (AWS) solutions, which remain one of the market leaders.

What can AWS CI/CD services offer in terms of features and added value?

If you are not familiar with AWS CodeCommit, CodePipeline, CodeBuild, or CodeDeploy, we offer an introduction to better understand the workings of the AWS DevSecOps environment. To provide an overview of the tools offered by AWS, we describe the functionality of these different services in the following paragraphs.

Let’s start from the beginning: From DevOps to DevSecOps

DevOps is a key element in the software development lifecycle of companies. DevOps relies on CI/CD tooling and is  pipeline on which the evolution of source code into a production-ready application depends. CI/CD accelerates the phases of build, test, and deployment to increase the delivery frequency of applications. This acceleration is made possible by automating many tasks within a CI/CD pipeline, which is a series of actions leading to production deployment.

DevSecOps adds security aspects to DevOps and relies on certain internal tools within the CI/CD pipeline. These tools integrate at every level of the CI/CD pipeline to scan the source code (SAST – Static Application Security Testing), dependencies (SCA – Software Composition Analysis), and more. The goal, as discussed in our previous article, is to integrate security as early as possible. The CI/CD pipeline is a significant component in ensuring the security of developments. One could even say that the CI/CD pipeline plays as important a role in secure development as Identity and Access Management (IAM) does in identity and access management.

CI/CD in AWS

AWS offers a multitude of services that not only provide classic infrastructure services but also allow the establishment of continuous development pipelines (from source code to deployment), while ensuring proper security testing.

The orchestrator CodePipeline organises and links the different stages of the CI/CD pipeline. This tool coordinates the progression within the CI/CD pipeline based on the results of other tools and services. If one of the tools returns a failure code, the pipeline can be blocked if necessary. The reasons for a pipeline failure can vary, such as insufficient code security score or tool deployment failure.

Code Management: SCM and AWS CodeCommit

Code version control systems (or SCM: Source Code Manager) are essential tools for collaborative code editing during  development and serve as the starting point for continuous integration pipelines. Currently, only three SCMs offer native integration: GitHub, BitBucket, and AWS CodeCommit. For any other integration with a non-natively supported SCM, you can create a serverless Lambda function-based routine and a webhook (HTTP notification) to download source code to AWS S3 with each developer commit.

AWS CodeCommit is the SCM service offered by AWS. It’s a code hosting service that supports version control and collaboration, similar to GitHub or GitLab, with Git commands. The advantage of AWS CodeCommit is its full integration with the AWS environment, making it easier to interconnect with other AWS services. Using AWS CodeCommit also allows for the use of AWS Identity and Access Management (IAM), avoiding the duplication of identity repositories and role management within a third-party SCM. All of this makes AWS CodeCommit a suitable solution when used within an entirely AWS environment due to its close integration with other AWS services. However, AWS CodeCommit offers relatively limited features compared to GitHub such as user experience and interface, and has a smaller community than GitHub or GitLab. If the CI/CD pipeline includes multiple solutions external to AWS, other solutions such as GitHub or GitLab will likely provide more flexibility.

Build Phase: AWS CodeBuild

Once development is complete, AWS CodeBuild takes over. This tool can be used for both compiling/building an application and running tests via CI runners. The service executes the instructions provided in an input file called buildspec.yml. It is a versatile tool, similar to classic CI tools like GitLab CI or GitHub Actions.

AWS CodeBuild also allows for running security tests (SAST, SCA, etc.) by installing and using applications on its runners. Take SonarQube, for example, a code quality tool with a SAST module for scanning source code to identify vulnerabilities. The execution works as follows:

1. When the source code is modified, a webhook notification (HTTP POST request from the SCM) is sent to AWS (in practice, this event is managed by AWS EventBridge or AWS CodePipeline), triggering the test.
2. The source code is duplicated on the CI runner, which scans it and produces a report.
3. This report is then sent to a SonarQube server (on-premise or on an EC2).
4. After analysis, SonarQube produces a final report indicating the code’s security level.
5. These results are sent to CodeBuild, which interprets, based on the conditions in the buildspec.yml file, whether the test was successful or not.

Again, the key advantage of CodeBuild is its integration with the environment, allowing close collaboration with other AWS services. For example, it’s easier to assign specific roles to CodeBuild projects, use AWS Secrets Manager (for secret management), or enable deployment with AWS CodeDeploy.

Deployment: AWS CodeDeploy

The deployment of an application marks the end of its development cycle. Within AWS, deployment is achieved through AWS CodeDeploy. Its role is to retrieve the artifacts and necessary configuration files from dedicated S3 buckets and deploy them on the chosen server (EC2, etc.). AWS CodeDeploy differs from AWS Elastic Beanstalk, which deploys an application solely based on its code (usually not supporting compiled languages like C/C++).

CodeDeploy operates by deploying code to any type of server, whether hosted by AWS or not. Its operation is simple: an agent (CodeDeploy agent) is installed on the target server. This agent is responsible for downloading the artifacts, installing them, and launching the application.

It is necessary to define in advance the instances involved in the deployment and assign them an arbitrary AWS tag for identification. All these instances then constitute a “deployment group.” When deployment is initiated, CodeDeploy selects the relevant instances and publishes its instructions. However, communication is initiated by the target instance; the CodeDeploy agent contacts the CodeDeploy service by polling for new instructions (polling mode). This communication method avoids opening ports, enhancing the security posture of the instance.

AWS CodeDeploy is an effective tool for deploying code to any type of infrastructure. However, it requires the installation of an agent managed by AWS on the instance where the code is deployed, which may not always be desirable depending on the client’s context. Polling by EC2 instances may impact the performance of a critical application or be detected as malicious by Endpoint Detection and Response (EDR) or Network Detection & Response (NDR) systems.

Securing the AWS CI/CD Pipeline

Given the critical role of the CI/CD pipeline in application development, it is essential to secure this infrastructure, including tooling, integration, and pipeline configuration. Below, we summarise some areas to consider when implementing an AWS CI/CD pipeline, which can be managed through the creation of AWS policies to alert or enforce their application.

Flow Management

By default, flows to AWS managed services (CodeBuild, CodeDeploy, etc.) transit over the internet before returning to the client instance of the resource. To avoid sending all flows to AWS services over the internet, we recommend setting up VPC endpoints. These network access points allow instances within a VPC to contact AWS services as if they were deployed within the VPC.

Secret Management

Secrets required to access services or other APIs should not be stored in plaintext in SCMs or pipeline configuration files. To avoid any leakage of confidential information during legitimate or unauthorised access to these directories, we recommend implementing an AWS Secret Manager to store secrets (e.g., SonarQube API keys) and distribute them to services only when necessary. Retrieving a secret is done through an API call to this vault, with privilege verification.

Supervision/Monitoring

Like any infrastructure, the CI/CD pipeline requires monitoring. Native AWS solutions for service monitoring include AWS CloudWatch for log collection, AWS EventBridge for creating alerts, and AWS SNS/SQS for sending notifications to predefined groups (email, SMS, push notifications, etc.). Monitoring the CI/CD pipeline allows for alerting against potentially dangerous production releases, for example, if a project attempts to bypass implemented security policies.

Identity and Access Management

Privilege management within AWS is based on Role-Based Access Control (RBAC) whereby each user action requires specific permissions. For example, if a user wants access to an S3 bucket, they must first obtain read permission associated with the corresponding S3 resource. It is essential to adhere to the principle of least privilege, which involves assigning clients (users and services) only the rights they need. AWS permissions allow for complete configuration of client access to each service/resource. However, the granularity of rights can be cumbersome to configure in a large-scale CI/CD infrastructure. AWS offers predefined roles that allow for quick application of sets of permissions. Still, these predefined roles often do not adhere to the principle of least privilege. Therefore, it is important to create roles that apply the principle of least privilege without delving into micromanagement of rights.

Our Beliefs on AWS CI/CD

The CI/CD solutions available in AWS cloud are interesting and natively integrated with other AWS services. Native integration is particularly useful in the case of a pipeline hosted entirely by AWS. When most of a company’s infrastructure is already migrated to AWS, you can take advantage of interconnections between services and powerful access management and monitoring solutions with minimal additional configuration. However, for a simple and isolated use case, AWS CodeCommit or AWS CodeBuild might not be the preferred choice. Solutions such as GitHub and GitLab offer more comprehensive solutions, better integration with other vendors, and a more user-friendly interface. Similarly, regarding security, AWS does not offer native CI/CD security services for code validation (SAST, DAST, etc.). AWS does not provide native integration, but third-party services can still be integrated relatively easily.

*Example of BitBucket Integration in AWS CodeBuild – Source

Cet article CI/CD in AWS: The Solution to All Your Problems? What You Need to Know. est apparu en premier sur RiskInsight.

As users have adopted this product en masse, it now raises several fundamental cybersecurity questions. 

Should companies allow their employees – specifically development teams – to continue using this tool without any restrictions? Should they suspend its usage until security teams address the issue? Or should it be outright banned? 

Some companies like J.P. Morgan or Verizon have chosen to prohibit its usage. Apple initially decided to allow the tool for its employees before reversing its decision and prohibiting it. Amazon and Microsoft have simply asked their employees to be cautious about the information shared with OpenAI. 

The most restrictive approach of blocking the platform avoids all cybersecurity questions but raises other concerns, including team performance, productivity, and the overall competitiveness of companies in rapidly changing markets. 

Today, the question of blocking AI in IT remains relevant. We propose to provide some answers to this question for a population particularly concerned with the issue: development teams. 

ChatGPT, Personal Information Collection, and GDPR 

OpenAI’s product is freely accessible and usable under the condition of creating a user account. It’s a known trend: if an online tool is free, its source of revenue doesn’t come from access to the tool. For the specific case of ChatGPT, the information from the history of millions of users helps improve the platform and the quality of the language model. ChatGPT is a preview service: any data entered by the user may be reviewed by a human to improve the services. 

Currently, ChatGPT doesn’t seem compliant with GDPR and data protection laws, but no legal decision has been made. The terms and conditions currently don’t mention the right to limitation of processing, the right to data portability, or the right to object. The US-based company OpenAI doesn’t mention GDPR but emphasizes that ChatGPT complies with “CALIFORNIA PRIVACY RIGHTS.” However, this regulation only applies to California residents and doesn’t extend beyond the United States of America. OpenAI also doesn’t provide a solution for individuals to verify if the editor stores their personal data or to request its deletion. 

When we delve into ChatGPT’s privacy policy  we can understand that: 

1. OpenAI collects user IP addresses, their web browser type, and data and interactions with the website. For example, this includes the type of content generated with AI, use cases, and functions used.
2. OpenAI also collects information about users’ browsing activity on the web. It reserves the right to share this personal information with third parties, without specifying which ones. 

All of this is done with the goal of improving existing services or developing new features. 

Turning back to developer populations, today we observe that the majority of code is written collaboratively using Git tools. Thus, it’s not uncommon for a developer to have to understand a piece of code they didn’t write themselves. Instead of asking the original author, which can take several minutes (at best), a developer might turn to ChatGPT to get an instant answer. The response might even be more detailed than what the code’s author could provide. 

Classic Attacks on AI Still Apply 

Today, over half of companies are ready and willing to invest in and equip themselves with tools based on artificial intelligence. Consequently, it will become increasingly important for attackers to exploit this kind of technology. This is especially considering that cybersecurity as a notion is often overlooked when discussing artificial intelligence. 

OpenAI’s AI isn’t immune to poisoning attacks. Even if the AI is trained on a substantial knowledge base, it’s unlikely that all of that knowledge has undergone manual review. If we return to the topic of code generation, it’s plausible that based on certain specific inputs, the AI might suggest code containing a backdoor. While this scenario hasn’t been observed, it’s not possible to prove that it won’t occur for a specific user input. 

We can also assume that the tool has been trained only on relatively safe web sources. The Large Language Model (LLM) on which ChatGPT is based: GPT3, could be susceptible to “self-poisoning.” As GPT3 is used by millions of users, it’s highly likely that text generated by GPT3 ends up in trusted internet content. The training of GPT4 could theoretically contain text generated by GPT3. Thus, the AI might learn from knowledge generated by previous versions of the same LLM model. It will be interesting to see how OpenAI addresses the poisoning issue as the model evolves. 

Poisoning is one technique for adding backdoors to AI-generated code, but this isn’t the only attack vector. It’s also possible that compromising OpenAI’s systems could allow modifying ChatGPT’s configuration to suggest code containing backdoors under specific conditions. A malicious attacker might even filter based on the user account identity of ChatGPT (e.g., an account ending with @internationalfirm.com) to decide whether to generate code containing backdoors and other vulnerabilities. Thus, it’s necessary to remain vigilant about OpenAI’s security level to prevent any rebound compromise. 

ChatGPT and Code Generation 

Code generation via ChatGPT is one of the features that can save developers the most time on a daily basis. For instance, a developer could ask to write a code skeleton for a function and then complete/correct the AI’s errors as needed. The main risk introduced by this practice is the insertion of malicious code into an application. 

However, the risk existed well before ChatGPT. A malicious developer could very well obfuscate their code and deliberately insert a backdoor into an application. However, the introduction of AI brings a new dimension to the risk since a well-intentioned user might inadvertently introduce a backdoor. This needs to be considered in the context of the organization’s maturity regarding its CI/CD pipeline. Conducting SAST, DAST scans, and various audits before production helps reduce the risk. 

We have observed that code generation via ChatGPT does not follow security best practices by default. The tool can generate code using insecure functions like scanf in C programming language. We provided the following query to the tool: “Can you write a function in C language that creates a list of integers using user inputs?” (initially prompted in French). 

Code generated by ChatGPT following the described user input 

Analyzing the code generated by ChatGPT, among other things, we notice three significant vulnerabilities: 

1. To begin, the use of the scanf function allows the user to enter any input length (int overflow…). There’s no validation of the user’s input, which remains a key vulnerability type highlighted by the OWASP TOP10.
2. Additionally, the function is sensitive to buffer overflow: beyond the 100th input, the list “list” no longer has space to store additional data, which can either end execution with an error or allow a malicious user to write data in a memory area that’s not authorized, to take control of program execution.
3. Finally, ChatGPT allocates memory to the list via the malloc function but forgets to free the memory once the list is no longer used, which could lead to memory leaks. 

So, by default, Chat GPT does not generate code securely, unlike an experienced developer. The tool proposes code containing critical vulnerabilities. If the user is cybersecurity-aware, they can ask ChatGPT to identify vulnerabilities in their own code. ChatGPT is fully capable of detecting some vulnerabilities in the code generated by itself. 

ChatGPT is able to detect vulnerabilities in code it has generated.

To summarize, code generation via ChatGPT doesn’t introduce new risks but increases the probability of a vulnerability appearing in production. Recommendations can vary based on the organization’s maturity and confidence in securing code delivered to production. A robust CI/CD pipeline and strong processes with automatic security scans (SAST, DAST, FOSS…) have a good chance of detecting the most critical vulnerabilities. 

ChatGPT isn’t the only online resource accessible to users that can lead to data exfiltration (Google Drive, WeTransfer…). The risk of data leakage already looms over any organization that hasn’t implemented an allow-list on its users’ internet proxy. The differentiating factor in the case of ChatGPT is that the user doesn’t necessarily realize the public nature of the data posted on the platform. The benefits and time saved by the tool are often too tempting for the user, making them forget best practices. In this sense, ChatGPT doesn’t introduce new risks but increases the likelihood of data leakage. 

An organization therefore has two options to prevent data leakage via ChatGPT: (1) train and educate its users and trust them, or (2) block the tool. 

For developer populations, once again, code generation via ChatGPT doesn’t introduce new risks but increases the probability of a vulnerability appearing in production. It’s up to the organization to assess the capabilities of its CI/CD pipeline and production processes to evaluate residual risks, particularly concerning false negatives from integrated security tools (SAST, DAST…). 

To make an informed decision, a risk analysis remains a valuable tool for deciding whether to potentially block access to ChatGPT. The following aspects should be considered: user awareness level, sensitivity of manipulated data, internet filtering paradigm, maturity of the CI/CD pipeline… These analyses should, of course, be balanced against potential productivity gains for teams. 

Cet article ChatGPT & DevSecOps – What are the new cybersecurity risks introduced by the use of AI by developers?  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.

In previous articles, we talked a lot about how security should be organised to accompany agile projects: the change in the security paradigm to ensure Security by Design, how to organise the ISS teams in the face of these changes, the possible methodologies for continuing to analyse risks or get security approvals (and a general reminder of what security looks like in agile).

These articles were mainly about the organisational and methodological paradigm shifts that ISS teams were undergoing, to be able to best support projects, which deliver code much faster.

The links between Agility and DevOps

By shifting the focus towards the development teams, it is now a question of dealing in greater depth with software solutions and processes enabling security to be integrated directly into the development pipelines and into the daily lives of developers, where Agile and DevOps methodologies, although they aim to provide the best value to customers, will be expressed differently.

As the DevOps movement was born later than Agile methods, development teams were organised earlier than operations in an iterative and rapid mode for application and service delivery. DevOps principles bridge this gap by bringing Operations and Development teams closer together, and by offering solutions to accelerate delivery through the strong automation of the software development lifecycle, via CI/CD pipelines. In the end, the two approaches feed off and complement each other, to deliver faster and with better quality, thanks to the automation of a large number of tasks, thus avoiding human errors.

What about security?

Back to our topic of interest, it is now a question of automating security as much as possible. Just like the Agile and DevOps methods, Security in Agile and DevSecOps are also closely related. The idea is to bring security closer and closer to the development teams, but also make it as fast as possible. A key profile of the security principles in Agile is perfectly suited to DevSecOps: the Security Champion. As described in the article “How to structure SSI teams to ensure security in Agile at scale“, this is the security ambassador within the development teams. They are an integral part of the product team and are present in every sprint. Their role is to ensure that security is considered in each sprint in the development of User Stories (by integrating Evil or Security User Stories already written, or by helping to write them). The Security Champion can come from the world of development and become more skilled in security issues, with the help of the Security Guild.

To take it a step further, the Security Champion can also help their team understand automated security solutions, with the help of a specialist from the ISS team, who will help them to develop their skills in application security.

Having said that, is it because Agile Security and DevSecOps are linked that one should automatically embark on a transformation programme towards DevSecOps?

Some preparatory questions for embarking on DevSecOps.

In line with any major transformation project, it is worth asking why you are doing it, making sure you have a plan and the right sponsorship. DevSecOps is no exception to the rule, even if the questions to ask are specific.

Defining the scope and objectives

Firstly, before you start, you need to identify your motivating factors. Is it to deliver faster? Better? More securely? Will the problems encountered by the Dev, Sec and Ops teams be resolved by bringing the skills together? This is to prioritise efforts and ensure that the project can be ‘sold’ to sponsors. Next, the scope must be identified, trying to delimit it between transitional scope (short and medium term) and target scope (long term). Work can start on an application portfolio, a factory for testing, followed by creation of a roadmap for deploying the model to the full scope.

The current maturity of the organisation in terms of tooling and automation in the product development cycle should be assessed. A good knowledge of the tools used in the pipelines is a prerequisite. If there are still too many grey areas, an inventory of existing tools and an inventory of the practices and processes in place should be put together first.

Presence of the essential building blocks of the CI/CD pipeline

Before security can be integrated into development pipelines in an automated manner, it is first necessary to ensure that we have a good vision of what a state-of-the-art pipeline might look like. It is possible to embark on a DevSecOps programme without operational pipelines already installed but having a clear idea of the target is key. Here are some examples of solutions:

Figure 1 – the essential building blocks of a DevOps pipeline

The company must also be able to quantify the developments carried out internally or externally, with development agencies. Indeed, a complete pipeline will be useful for companies developing mainly in-house: it is an indispensable tool for developing quickly, with the right security tools integrated into the pipeline. In the case of external developments, the principle is different, and security is less “easy” to control: agencies will not necessarily give access to their pipelines or their source code. They may only deliver executables or images, via remote repositories for example. Integrating security is therefore done by more traditional means: via Security Assurance Plans (SAPs) for example, or by contractually obliging agencies to train their developers in application security, via training software solutions (for example CodeWarrior, which delivers ‘belts’ according to the level of training achieved).

Secondly, one of the most important ideas is that the pipeline is built in stages. In line with the “test and learn” approach dear to Agile methods, a “pilot” version of the pipeline can be deployed for a volunteer product team to test it over a few weeks/months. The deployment is then carried out progressively, according to a pre-established roadmap. In most cases, companies first set up a DevOps pipeline, with a few codes analysis tools (most often quality-oriented), then, once the pipeline is considered functional, the security tools are added.

However, it could be worthwhile to consider security tools as an integral part of the CICD pipeline. They could then be integrated into it progressively, according to a prioritised roadmap, as proposed below.

Here are some examples of tools that make up the security stack:

Figure 2 – Examples of security solutions to be integrated into the CICD pipeline (DevSecOps)

According to our feedback from the field, some tools are “easier” to implement and are therefore implemented as a priority.

Static Application Security Testing (SAST) tools

As mentioned earlier, these tools are nearly always already present in the initial pipeline, in their code quality testing format. Here it is a matter of configuring them to go one step further and perform security analysis of static code. This type of tool can be integrated at several points in the pipeline, in a “shift-left” logic, i.e., integrating security as early as possible in the pipeline. It can be positioned directly on the developers’ IDEs (integrated development environment), to provide them with “real-time” feedback on errors that could introduce vulnerabilities. It can also be used at the time of code compilation.

A disadvantage of this type of tool is the high number of false positives. The configuration is scalable and improves over time. However, the governance and processes around the tool need to be thought out in advance: a vulnerability triage team can be a solution, as well as training security champions to spot false positives, with the help of an application security expert (an Application Security Engineer for example).

SCA (Software Composition Analysis) tools

These tools should logically be installed as a priority, as developers make great use of open-source libraries to develop their products. The SCA will check the components of the library, such as licences, dependencies, vulnerabilities, and potential exploits. Many attacks originate from the uncontrolled use of open-source libraries that may contain critical vulnerabilities (such as the Log4Shell exploit).

This tool can be used like SAST, on IDEs or before compiling the code.

DAST tools

DAST tools scan running application builds for security vulnerabilities. They allow the simulation of a malicious attacker’s behaviour through automated pen tests and detect common security vulnerabilities such as OWASP 10. These tools may be less easy to use in authenticated mode (authentication is difficult in automatic mode, it must be done manually before running a test). The tests also take longer than a static scan, and dedicated time must be set aside so as not to disrupt the work of developers or production.

They can be used at the time of testing, but also in production.

It is necessary to think very early on about the governance and processes to be put in place around these tools, in particular by ensuring that developers cannot ignore detected vulnerabilities (by passing them as “false positives”, for example) and to ensure that vulnerabilities are centralised in a single tool (vulnerability management tool, for example), for greater efficiency.

Checking the presence of enabling technical prerequisites

The interest in working in DevSecOps may be limited on non-configurable and non-instantiable software package type applications.

On the infrastructure side, Infrastructure as Code (management and provisioning of infrastructure via code rather than manual processes) allows the use of containers or provisioned VMs that are key to use CICD pipelines more efficiently.

Not forgetting the whole governance and change management layer around the project

Make sure you build, or already have, an operating model that meets your needs (security champions, enabler teams, tooling, processes). Working in “agile at scale” mode is not mandatory for the first iterations (depending on the scope chosen).

Using a “test and learn” method to experiment is a good way to involve the teams very early on, and to get complete and relevant feedback from the field, before starting to deploy at scale. Cybersecurity experiments have been carried out with clients to find out what types of practices or tools to implement.

Some examples:

– Purple teaming to allow developers to see the results of another team’s testing tools and attempt to exploit them (allowing developers to see the reality of an attack and the potential ease of carrying it out),

– Implementing solutions such as Cloudbees, to automate the CICD pipeline processes,

– Training Security Champions to interpret the results of security tools.

These experiments also act as change management, as most stakeholders can be involved early in the transformation programme.

In conclusion

CICD pipelines are a real opportunity for security to become automated. By integrating the right tools into the pipeline, developers are supported in their practice, kept on real security guardrails, facilitating the development of a secure product.

In addition to securing the products, it is also a question of securing the pipeline itself, in the same way as any component with broad access to the information system: it is a question of controlling access to the various tools that make up the pipeline, ensuring that secrets are properly managed, that the underlying servers are hardened, etc.

In a future article, we will detail our views on the pillars of DevSecOps, or how to achieve a sustainable and effective transformation (based on shift-left, guardrails and empowerment of the teams on security!).

Any comments or corrections? Do not hesitate to contact us!

Cet article Security in Agility and DevSecOps: linked fates? est apparu en premier sur RiskInsight.

Historically, the Agile approach is a set of practices used for IT development projects. 

The Manifesto published in 2001 proposes 4 main values to revolutionise the performance of companies:

This emphasis on human interaction between the development team and business teams aims at reducing the time to market of the products developed, as opposed to projects conducted in V-model which, once delivered, may no longer satisfy changing business requirements.

Today, this practice is applied in most companies at all levels. In the latest State of Agile Report, out of more than 4,000 companies surveyed worldwide, 95% declared that they use agile and 65% of them have been practising it for at least 3 years.  In addition to IT, the methodology is also used in marketing, human resources, sales, and finance departments. 52% of the companies surveyed stated that at least half of their company’s departments adopt agile processes and therefore the scalability of such practices should not be ignored.

Beyond a project management method, it is a new philosophy with gamified elements. We no longer speak of meetings but of ceremonies, with new roles appearing such as product owner and scrum master. Using this philosophy, the desire is to create an atmosphere of co-construction and to make maximum use of collective intelligence to improve the company’s performance.

Although the concept of security is present in the manifesto, the integration of such measures into product development is not properly addressed. The method by which security is implemented in V-model projects does not apply to the agile philosophy and thus new ways of implementing security should be identified for it.

What are the trends and challenges of this field?

One of our challenges is to provide our clients with a global view of their problems. Adopting an agile approach requires a change in all levels of the business from security, to quality teams and as such the effect on all levels of the business must be considered.

In terms of organisation, the ISS must reposition itself as a service to the business and thus shift its image from a ‘policeman’ to a support function. The role of Security Champion (a member of the feature team such as a developer) becomes the point of contact for the ISS teams. In doing this a connection can be created with each feature team, thus increasing autonomy over security integration. This is not something that can be achieved overnight, it requires training to highlight cybersecurity issues and share knowledge (particularly the basics of ISS and secure development). In addition to this, a security Guild should be created, bringing together ISS experts, security champions as well as security enthusiasts. This allows members to exchange information on the latest security news, good practices as feedback and lessons learned from the field. This Guild must be set-up in such a way to allow easy communication between members (such as on an internal wiki).

After the security champion receives training from the ISS team, they become the security referent and thus developers can turn to them for questions and advice. Therefore, the role in itself is fairly technical. In adopting an agile approach, the ISS experts will keep their role, but the relationship will change from that of control and audit to support and facilitative. Audits can still be carried out (such as penetration tests) at the request of the feature team or on the initiative of the security experts. Methodological tools must also be available to help the Champions in their tasks and this includes rewriting risks in conversational format. To adapt to the use of User Stories by feature teams, the ISS team could try writing Evil User Stories, which correspond to an action carried out from the point of view of an attacker. For example:

Faced with these risks, there are Security User Stories, proposing remediation solutions for EUS, with ready-to-use acceptance criteria. All this can be integrated into a security baseline (also in backlog format, in a product management tool, such as JIRA for example), proposing a minimum-security base to be integrated into the products.

In addition to organisational support for the teams, technical support must be provided by optimising the continuous integration and deployment chain (CI/CD) with tools aimed at automating security as much as possible, which can be called the Security Stack or Security Pipeline: code review, vulnerability scans, detection of secrets, security of the Infrastructure as Code, etc.).  Particular attention must be paid to its own security, so as not to produce the opposite effect… From a shift-left security perspective, security is integrated into the product by default, right from the start. It therefore adapts its velocity to that of an agile approach and enables a shift from a DevOps logic to that of DevSecOps. 

Another role can be created, that of AppSec Manager. This is part of the ISS team and is an expert in software security as well as an expert in the security stack. Their role is to help the developers to prioritise and remedy the vulnerabilities reported by the Stack. They work in tandem with the Risk Manager/IS expert, who provides them with knowledge of the risks associated with the product, which enables a more detailed analysis of the vulnerabilities to be dealt with as a priority. All this helps to create a culture of security by design.

What do customer expect?

CISO customers expect to be reassured that security in agile mode will not cause them to “lose control” over the proper implementation of security. The model we propose empowers the feature teams, gives them tools, but security retains control by centralising the performance indicators, by having the capacity to carry out random checks/according to predefined criteria, via bug bounty for example or an envelope of pentester days, to be distributed over the various products.

Secondly, as a consultant, I think that clients expect us to share our convictions and very concrete examples of what we have been able to achieve for other clients. To meet this demand, Wavestone’s Cybersecurity and Digital Trust (CDT) practice has created several methodological accelerators based on feedback from the field, ready to be shared and adapted. Being able to carry out the mission in Agile mode was also part of the expectations, favouring co-construction rather than providing fixed and almost finalised deliverables from the first draft. In this gamification perspective, which is very important from an agile approach, we offer original co-construction workshops based on collective intelligence, thanks to our Creadesk asset, which trains consultants and provides them with tools for remote collective work.

Any final advice for our readers?

Implementing a true test & lean approach is crucial. In order to extract the most benefit from using co-constructing tools, we must regularly test and verify them in the field. While anticipating problems is crucial, significant value can be achieved when one we confront the problems as they arise. It allows us to be in direct contact with the business and feature teams, to show them that concrete actions are being implemented. The approach is agile, flexible, and scalable. The accelerators, methodologies and tools proposed evolve during the pilots and become even more relevant for the second wave of pilots, until all the feature teams are integrated.

At the same time, it is important to remember that change management is essential. A real communication plan is needed – building communities of practice/guilds from the beginning of the pilots and identifying early adopters who will be valuable drivers of change within the teams. Agile has a real and rapid impact in everyday life and at all team levels: implementing this change is essential.  

Cet article Agile Security, Emma Barféty interview est apparu en premier sur RiskInsight.