Secure SDLC (Part 2): ASOC, ASPM, DevSecOps and the AppSec future

Dive dive into Secure SDLC by SecChamp, senior engineer and AppSec manager

Intro

We continue to research the issues of application security (appSec), the secure software development cycle (Secure SDLC)and DevSecOps. Let’s compare orchestration platforms (ASOC and ASMP), define key metrics, KPIs for the AppSec manager, and also talk about confusion in terminology and the future of secure software.

Small companies and startups often used open source software to solve application security problems. Larger and more mature teams connected commercial solutions to them. But all this is already in the past. Today, all-in-one automation offers entire security platforms that are qualitatively different from manual control mechanisms. And so, let’s look!

Application Security Orchestration and Correlation (ASOC)

Birth of technology

In 2018, Gartner identified the Application Security Testing Orchestration (ASTO) space in its annual Application Security Hype Cycle report, and in 2019 the segment was renamed Application Security Orchestration and Correlation (ASOC).

Today, Gartner estimates market ASOC from 5% to 20% for customers in the target audience. However, in practice we see much less adoption of this technology. According to Gartner, one of the main barriers to the implementation of ASOC solutions remains the extremely low level of awareness of the fact of their existence, although interest in them is growing rapidly. Unfortunately, very often software development organizations focus their efforts on a more traditional approach in the so-called “patchwork automation” format, which is absolutely not scalable, unlike ASOC.

What is ASOC?

So, a full-fledged ASOC platform are consist of:
· integrates security analysis tools — Application Security Tools (SAST, DAST, SCA, etc) with the software development stack (DevOps);

· provides transparent real-time interaction between engineering teams and information security experts (SecOps, AppSec, DevOps, QA);

· and implements automated management of the process of creating secure software products based on data obtained from production pipelines (DevSecOps pipelines).

A schematic representation of the DevSecOps process and the place of the ASOC platform in it can be depicted in the form of the following diagram:

From the point of view of the DevSecOps process, the ASOC platform manages calls to all information security tools at each stage of the software product life cycle (SDLC), records analysis results for each version of the application artifact, and controls the security level of the final distributions based on the statuses of all the latest versions of elements and components included in them.

Well, the ASOC platform for full DevSecOps management should implement a full range of tasks from all three domains (functional areas) — Orchestration, Correlation, Analytics.

From the point of view of the main vectors influencing the DevSecOps process, we identify three — Software Engineering, Security and Business. Stakeholders from these three groups are interested in a workable process and results, but each has their own goals and motivations.

· Software Engineering — implement business functionality on time, according to the sprint and release plan; improve the engineering process to improve software quality;

· Security — increase the security of digital products and ensure the continuity of their operation, ensure compliance with industry requirements and regulatory requirements;

· Business — maintain a balance between the level of security of digital products and security costs, reduce Time-to-Market;

To simplify visualization, we present our metrics model in a DevSecOps metrics pyramid consisting of four levels (see it below):

(1) Telemetry layer is a layer of simple, disconnected data that can be obtained from any source. Example — industrial standards data, scanning time for a software artifact, size of the code base, number of tasks in a certain pipeline, number of vulnerabilities detected by a scanner in any artifact in a certain version of a particular software product, etc.

(2) Operations layer is an information layer that is derived from telemetry parameters. Example — the volume of technical debt, defect density, average defect lifetime, etc. Parameters at this level are typically controlled at the individual command level.

(3) Operation management level is a layer of generalizing concepts that aggregates the parameters of the operational level. Example — Time-to-Market for a specific release, covering product teams with Application Security practices, eliminating vulnerabilities in a software product, etc. Concepts at this level are usually controlled at the management level of the company.

(4) The level of Top Management (Executive) is the highest layer of categorization and abstraction. At this level there are generalized concepts that are decomposed through connections with parameters from all underlying layers. These are Time-to-Market, Digital Business Continuity & Security, Compliance, Software Development Maturity. Achieving goals in all these areas forms the overall value of implementing DevSecOps for the organization (DevSecOps Value).

In the context of the engineering process, we can highlight the main basic metrics and indicators that should be supported by ASOC class solutions:

TABLE

Schematically, the relationships between DevSecOps metrics within the production process are presented in the diagram below:

The ASOC functional areas

(1) Orchestration​​​

To simplify the management of the DevSecOps process, the platform operates on the concept of basic elements of a software product (so-called Software Assets ) — code repositories, build artifacts, distributions, containers, instances of applications deployed in testing and production environments. Also, as part of the orchestration process , for greater flexibility, the software product (application) can be decomposed into structural components (the so-called Structure Units ) — modules, microservices , since a separate engineering team is often responsible for their implementation.

Information security tools:

• SAST: Checkmarx SAST, Fortify SAST, Veracode, SonarQuber ;
• OSA/SCA: Sonatype, Synopsys BlackDuck ;
• DAST: Netsparker , Acunetix , Stingray ;
• CA: Aqua Security, Clair ;

Development Tools:

• Source code repository: GitLab , GitHub , Git , Bitbucket ;
• Artifactory : Sonatype Nexus Repository, JFrog;
• CI/CD: Jenkins, TeamCity, CircleCI , GitLab CI;
• Defect management: Jira , etc;
• Containers: Docker ;

The ASOC allows you to create and configure all the necessary information security pipelines for each type of software product element. Pipelines can be created automatically using pre-existing templates — this greatly reduces the labor costs when initially introducing a large number of applications into the DevSecOps loop. For each pipeline, a history of its launches is maintained and the results of all tasks are tracked, and all data is placed in storage for subsequent analysis.

ASOC allows you to create and configure all the necessary software quality control points (Quality Gates), which determine the criteria for successful security scanning. Profiles with threshold values and criteria for passing these control points are created separately, and the control points themselves are added to the pipeline as part of the scanning task configuration process.

(2) Correlation​​

The use of various tools and technological practices when identifying software vulnerabilities generates gigantic volumes of data. Within the ASOC technology, the vulnerability correlation mechanism is the basis of the secure software production pipeline.

The correlation mechanism allows:

• filter false positives;
• identify and merge duplicate vulnerabilities;
• group vulnerabilities into defects based on context;
• monitor the status of resolved vulnerabilities during subsequent
  (full and/or incremental) scans;
• generate and accumulate data on typical vulnerabilities, enriching them with information on methods of identification and elimination.

This approach greatly reduces MTTR ( Mean -Time-To- Resolve) in the DevSecOps cycle, allows teams (Ops, Sec and Dev) to focus on critical vulnerabilities and allows engineers to increase the speed of recognizing emerging threats in software products being developed.

ASOC matching engine minimizes labor costs for vulnerability analysis using a special Application Vulnerability engine Correlation (AVC) and a number of filters for working with lists of vulnerabilities.

AVC uses machine learning technologies to analyze vulnerabilities and filter out false positives. The model was trained on more than 1 million manually analyzed vulnerabilities. AVC analyzes the source code along with the data and makes a prediction about the vulnerability status.
To vulnerabilities marked as True Positives , correlation rules are applied to group them into information security defects. Correlation rules are based on parameters such as type, CWE ID, file name, line of code number in the file, status, category and severity of the vulnerability.

The process of managing software vulnerabilities and information security defects

1. Vulnerabilities are detected by security analysis tools during the scanning process of software artifacts called from the DevSecOps pipeline.
2. Analysis tools are the main sources of vulnerability data. Once the scan is complete, the data is imported into ASOC.
3. Information security defects are created based on vulnerabilities. One information security defect may correspond to several vulnerabilities, since they may have a common cause in the source code of the software product.
4. Defects are created in ASOC and exported to defect management systems.
5. For greater flexibility, information security defects can be assigned tags, and categorization can be implemented based on the “Label” and / or “ Component ” attributes, in the case of Jira , to track defects within a specific structural component of the software product, controlled in ASOC .
6. To simplify the process of fixing defects, ASOC supports several options for assigning a defect to the responsible specialist in the development team’s defect tracker . Such a specialist can be in the following roles:
   — team leader of the development team, responsible for the entire defect management process within the framework of a specific project in Jira ;
   — a leading engineer responsible for the defect management process within a specific software component; — a dedicated Security Champion, responsible for the entire range of information security tasks in the engineering team;
7. ASOC constantly monitors the status of vulnerabilities and compares the results of scanning new versions of applications with fixed defects with the results of analyzing previous versions of applications within the configured pipelines . Based on the scan history and defect resolution history, the platform performs an automatic check and confirms that the defects have indeed been fixed.

(3) Intelligence

DevSecOps data analytics allows you to analyze the security status of applications across all teams and applications in the organization. ASOC might aggregates engineering and security data in a data warehouse (DWH) and offers a set of metrics and dashboards to work with that data.

Data collection, aggregation, and analysis help implement data-driven secure application development. This gives management, development, operations and security teams complete visibility into security and software engineering.

As part of monitoring the DevSecOps process, at first glance, the tasks and, as a result, trends that need to be monitored are quite obvious, for example:

· Reducing the time to eliminate detected information security defects;

· Reducing technical debt;

· Reducing the number of failed software checks at different stages of development;

· Reducing the number of vulnerabilities found during security audits/pentests;

· Increasing the coverage of security checks for developed applications and code base;

· General improvement in the quality and security of developed products;

· Increasing the maturity and sustainability of the DevSecOps process;

Next Level: Application Security Posture Management (ASPM)

Application security posture management (ASPM) is an application security approach that leverages holistic visibility into the application environment, automation, and comprehensive security measures to implement, measure, and improve application security programs.

ASPM introduces an asset-first approach that allows organizations to prioritize their most critical assets (repos, teams, endpoints, web servers, etc.) based on business importance, irrespective of security tooling data. This enables AppSec teams to allocate limited resources effectively and focus on vulnerabilities that have significant business impact rather than getting overwhelmed with a backlog.

Gartner identifies 7 key core components of an ASPM solution as follows:

1. Coverage: Includes all AST technologies and development infrastructure, from code to runtime. For example, an ASPM solution has to connect to the SCM (source code management system), other SDLC systems and infrastructure, and also to the runtime environment where the application that went through this pre-production development environment ultimately deployed.
2. Testing orchestration: This includes the ability to integrate testing tools into the pipeline. For example, controlling which tests will be running as part of a pull-request check.
3. Remediation: An ASPM solution needs to provide guidance on how to fix vulnerabilities and help establish remediation workflows by identifying ownership, enabling triage, integrating with ticketing and alerting systems and more.
4. Correlation: A key ASPM capability, correlation refers to data grouping of similar characteristics to allow better prioritization and faster remediation. For instance — looking at all vulnerabilities originating from the same file, or relevant to the same container. In some cases, also merging duplicate findings that reference the same problem.
5. Prioritization and triage: ASPMs provide data and context to make better decisions — which can be intelligent risk scoring, prioritization based on business context and application criticality, and more. Most development shops have huge risk backlogs and need to surface the most critical risks to fix at any given time with their limited resources and ASPM can help.
6. Root cause identification: Providing the means to either manually or automatically identify root causes for risks by leveraging traceability. For example, it is possible to identify the file or component that is responsible for the most risk or point out to a project that adds significantly more vulnerabilities over time relative to others. This makes remediation efforts more efficient by addressing the risky sources and trends.
7. Risk management: ASPM solutions can aggregate and report on the overall application risk, by means of scoring, calculating business risk and impact, and more. This allows an organization to make better decisions, set goals and track progress over time.

ASPMs can add value in two other very important areas:

• Software supply chain security — ASPMs can protect the SDLC itself in addition to the application builds that flow through it. Software supply chain attacks have increased between 3–6X annually in recent years, and protecting this attack surface has become an essential security need. This includes the need to secure CI/CD pipelines, SDLC systems and infrastructure, generate SBOMs and verify application integrity.
• Application security testing out-of-the-box — ASPM solutions can also provide their own native security scanning capabilities, such as secret scanning and IaC scanning. An ASPM should provide orchestration capabilities to the security scanners that come with the solution, in addition to connecting to pre-existing 3rd party vendors.

ASPM vs. ASOC

ASPM and ASOC are two distinct but related concepts in application security, ASOC evolved into ASPM, and remains a key feature of ASPM solutions.

ASOC is an approach to managing and automating application security processes. This approach orchestrates and automates:

• security tasks,
• the correlation of data from various sources,
• threat intelligence integration,
• robust reporting and analytics,
• and workflow management.

ASOC enhances efficiency, collaboration, and visibility in application security practices, which helps organizations proactively identify and respond to security risks to improve their security posture and reduce the likelihood of breaches.

ASPM evolved out of ASOC, with the latter being one of the key capabilities in the former. ASOC tools were the first centralizing tools to bring vulnerabilities from application security tools together. ASPM tools bring the concept of ASOC a step forward, shifting from just managing vulnerabilities, to managing and scaling an AppSec program based on risk.

ASPM is Projected to Grow Fast

Gartner predicts growth from 5% to 40% adoption of ASPM within only 3 years. Like Gartner, we believe that ASPM is becoming essential to modern application security, especially for organizations with complex development environments, DevOps, CI/CD, distributed teams, and complex application portfolios.

“By 2026, over 40% of organizations developing proprietary applications will adopt ASPM to more rapidly identify and resolve application security issues.”

Gartner’s Innovation Insight for Application Security Posture Management (ASPM)

Measuring The Success Of Your ASPM Program

The following key performance indicators (KPIs) are helpful when measuring the success of your new ASPM program. You’ll notice that these KPIs look at an organization’s overall security posture, efficiency metrics, as well as the developer experience:

1. Vulnerability detection rate
2. False positive rate
3. Mean time to remediate
4. Coverage of application portfolio
5. Compliance adherence
6. Number of high-risk vulnerabilities
7. Incident response time
8. Cost of remediation
9. Developer feedback on tool usability
10. Incident response collaboration

Secure SDLC or AppSec or DevSecOps?

There are many concepts and terms in the topic of cybersecurity. Newbies and even experienced security engineers often get confused about them. In non-professional literature, one term often replaces another, hence some confusion and confusion arises.

So. AppSec is application security in the context of securing primarily source code and binary code that runs on infrastructure services. This term may well include Secure SDLC. AppSec includes covering security issues throughout the use of software — from source code storage to the creation of binary artifacts, their launch in infrastructure services, compliance, patching and support for end users. Essentially, this is a set of policies, practices, technologies, mechanisms, and activities to ensure high-quality and secure software.

Secure SDLC is the process of introducing security into the standard software development cycle (SDLC). These are more than purely technical means — static analysis, dynamic analysis, testing at the stages of code merging and application assembly. This also includes threat modeling, setting security requirements, describing risks and measures to reduce their impact, mitigation plan, and verifying written code. We can say that Secure SDLC is the basic story for providing secure software. And this is included in the more capacious term AppSec.

DevSecOps as a direction arose quite recently, after the emergence of e.g. Docker, Kubernetes and similar technologies. Essentially, DevSecOps is accelerated DevOps with a focus on production cybersecurity. If AppSec and Secure SDLC are more about the security of code (source and compiled into binaty artifacts), then DevSecOps is more about the infrastructure security of such key elements as the Cloud environments (AWS, GCP, Azure), CD\CI platform (GitLab), orchestration container system (Kubernetes), container virtualization (Docker), code repository (GitHub), artifact storage (J-frog), and of course the servers themselves (VM, EC2) on which all this is running (Linux, nginx, Apache, etc)

Secure SDLC = secured software application?

Before moving on to the topic of Secure SDLC, let’s talk a little about what should be understood by the term Software Development Life Cycle (SDLC). It is a framework that describes the software life cycle. Its task is to help businesses build quality application development processes. The corresponding recommendations are described in the international standard ISO/IEC 12207:2008. The framework itself consists of a familiar set of steps — design, deployment, testing, support and others.

Over the past five years, the number of software vulnerabilities has increased by 30%. A significant part of the problems arises due to the low efficiency of the development process, so the increased interest in the development cycle of secure applications — Secure SDLC — is understandable.

Just a bit of statistics (as of year 2021 data):

· 88% of users care about how secure your app is. It is to the point they will not use services if they are not secure;

· 38% of users will never come back. It is after the news of the data breach or if there is information about misusing users’ data.

Secure processes not only reduce the risk of hacks, but they literally save money. Fixing a bug at the implementation stage costs six times more than a vulnerability discovered during design. Other estimates suggest that the cost of fixing bugs after release increases by a factor of thirty.

There are several Secure SDLC models, but perhaps one of the most famous is MS SDL. The basics of the concept were formulated by Bill Gates twenty years ago, but since then it has been adjusted to take into account new approaches and technologies. In particular, software design within MS SDL involves threat modeling at the component level, dynamic code analysis and fuzzing testing. All development team members undergo information security training and study best practices in this area.

According to reports, Bill Gates’ initiative has increased the corporation’s competitiveness in terms of information security — between 2004 and 2010, the number of vulnerabilities in its applications decreased by almost three orders of magnitude compared to other organizations. Immediately after this, the company decided to release the developments under a Creative Commons license, and the MS SDL model became a kind of canon from which other Secure SDLC approaches are based.

Microsoft Secure Software Development Lifecycle (SSDL) is a software development process created and made public by Microsoft back in January 2004. It is based on the SDLC spiral model. During the initial period of its development, the emergence of this practice mainly benefited the company by reducing software maintenance costs and increasing its reliability. Versions 1 through 3 of SSDL were only released to the public in January 2006. Version 3.2 was released in 2008.

Subsequent versions of Microsoft’s SDL have focused more on software reliability, security vulnerability patching, threat modeling, compliance, reporting, cryptography standards, and incident response. Microsoft Secure Development Lifecycle, version 5.2 (marketed in 2012), has become the industry’s leading model for software security practices. It has been widely accepted by private and public companies around the world.

Among them we can highlight OpenSAMM by OWASP community. With its help, you can assess the current level of maturity of the software development cycle and outline changes in the security context. According to the concept, the application development process includes twelve components — for example, code review and security testing, as well as improving the literacy and level of cyber hygiene of employees. Each component is rated on a scale from zero to three, where the number three implies complete mastery of information security practices in this area.

Another model for building a Secure SDLC is called BSIMM. It is a thematic reference book with examples of best practices and mechanisms. A business can compare its processes with the processes of hundreds of companies and, based on this, adjust goals and objectives. In total, the framework includes more than 120 different methods that cover twelve stages of the application development and deployment life cycle.

DevSecOps = Infrastructure security or product environment?

DevSecOps integrates application and infrastructure security seamlessly into Agile and DevOps processes and tools. It addresses security issues as they emerge, when they’re easier, faster, and less expensive to fix, and before deployment into production.

Application security (AppSec) = Secure SDLC?

The terms “application security” and “secure SDLC” are often used interchangeably. However, there is in fact a difference between the two. Information security pioneer Gary McGraw maintains that application security is a reactive approach, taking place once software has been deployed. Software security, on the other hand, involves a proactive approach, taking place within the pre-deployment phase.

To ensure that a piece of software is secure, security must be built into all phases of the software development life cycle (SDLC). Thus, software security isn’t application security — it’s much bigger.

AppSec in a simpler sense is the security of all software beyond its development stages. And DevSecOps is security focused on Agile-oriented development teams using appropriate tools and technologies. But overall security, what the company wants to do and what the end user gets, is achieved by bringing all these parts together. The final security of the product is AppSec (include Secure SDLC) + DevSecOps in action.

The future of security

As technological solutions have become more available and popular, businesses are increasing their usage of them. Due to this movement, the global DevSecOps market is set to grow tenfold by 2029, hitting £19 billion, showing a CAGR of 31.5%. Automation and consolidated development processes have allowed businesses to increase efficiency within their team and operations, saving both time and money in the process.

Sources: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13