5 Security Stages of the DevSecOps Pipeline

ImagineX Consulting > Blog  > 5 Security Stages of the DevSecOps Pipeline

5 Security Stages of the DevSecOps Pipeline

Cybersecurity has been front and center in 2020 as the number of daily cyberattacks increased by 400% following the start of the pandemic.  To combat these threats, organizations must continuously strengthen their security posture by evaluating risks, training employees, and protecting infrastructure and applications.  Many security vulnerabilities are exposed through organizations’ custom web and mobile applications.  Fortunately, there are some simple steps that organizations can take to identify and mitigate these vulnerabilities before they are exposed to attackers.

 

Many organizations use CI/CD pipelines to facilitate the build and deployment of their custom applications.  Although CI/CD pipelines are just one small piece of the software delivery process, they can prove to be critical in detecting vulnerabilities in application code.  In fact, if we look at the recent SolarWinds attack, Microsoft states that 

 

Therefore, insertion of malicious code into [file name] likely occurred at an early stage, before the final stages of the software build…

 

This indicates that there were likely security vulnerabilities that were preventable during earlier stages of the build process.

 

One way to enhance security during the build process is to incorporate automated security checks at various stages of the CI/CD pipeline.  In essence, this creates a DevSecOps pipeline.  Whether an organization uses Jenkins, Azure DevOps, CircleCI or another CI/CD platform, these automated security stages integrate seamlessly.  Here is a look at the 5 security stages of the DevSecOps pipeline.

 

 

Stage: Software Composition Analysis (SCA)

When: After building the code

 

Software Composition Analysis (SCA) scans open source libraries used within an organization’s code base and identifies vulnerabilities.  It can also detect open source licensing changes that conflict with the organization’s software licensing policies. Many software applications today contain at least one open source component which makes SCA valuable at most organizations.  In the pipeline, SCA should run just after the build step. The pipeline should be configured to fail if any SCA issues are detected.  Snyk Open Source is a widely used SCA tool that fits well into any platform.

 

Stage: Static Application Security Testing (SAST)

When: After building the code and after SCA

 

Static Application Security Testing (SAST) scans an organization’s entire code base for a broad range of vulnerabilities, including the critical risks identified in the OWASP Top Ten.  SAST is a common and powerful method that should be used by all organizations due to the vast number of tools available and their ability to detect basic vulnerabilities in an organization’s code base.  A SAST tool should be configured to run just after the build step.  After the scan is complete, the SAST tool can publish results directly to the build console and prevent the pipeline from moving forward if security standards aren’t met.  Some tools that do SAST and integrate easily into the pipeline are HCL AppScan, SonarQube, and Checkmarx.

 

Stage: Container Scanning

When: After container images have been created

 

Container scanning is a process that scans containers and container images for vulnerabilities.  For organizations that use Docker or Kubernetes to run custom applications, this is a great tool because it will verify that those containers are safe.  Container scanning will detect open bugs in dependent libraries and base images, and detect licensing changes.  Container scanning is performed after the build produces new container images.  It should scan the image before it is uploaded to a container repository.  If it finds any vulnerabilities in the image, it should fail the build and prevent the image from being uploaded.  Tools to consider for container scanning include Qualys Container Scanning and Aqua.

 

Stage: Dynamic Application Security Testing (DAST)

When: After the application has been deployed to a test environment

 

Dynamic Application Security Testing (DAST) crawls a running application and attacks it as if it were a malicious user.  DAST can detect issues such as XSS, unencrypted data transfer and TLS certificate verification.  DAST should be performed after the application has been deployed to a test environment.  The pipeline process should be configured such that results are analyzed and the pipeline is halted if any unacceptable vulnerabilities are found.  Many DAST tools are part of security suites that also include SAST.  These include tools such as HCL AppScan and MicoFocus Fortify.  A popular tool for mobile apps is NowSecure.

 

Stage: Interactive Application Security Testing (IAST)

When: When automated or manual tests are being conducted

 

Interactive Application Security Testing (IAST) is a form of testing that monitors an application as it is being used either by real users or automated tests such as a DAST scanner.  As the user or script navigates through the application, the IAST tool collects information about vulnerabilities in the application.  It can detect things such as unencrypted data, file system, and database access.  IAST should be performed after the application has been deployed to a test environment while automated or manual tests are being conducted.  Some IAST tools include Synopsys Seeker and Veracode.

 

As we enter 2021, we should expect cyberattacks to remain a key concern for all organizations.  Organizations that build custom web and mobile applications should look to create a DevSecOps pipeline that incorporates the 5 security stages: SCA, SAST, Container Scanning, DAST and IAST.  The stages can be implemented one at a time or all together.  By creating a strong DevSecOps pipeline, organizations can be confident that application vulnerabilities will be detected early, helping build the foundation for a stronger security posture.

Ryan Manns