June is application analysis month in the Red Hat’s monthly Security series! Beginning in March 2021, the Red Hat Security Ecosystem team has provided an introduction to a DevOps Security topic in a monthly fashion to help you learn how Red Hat weaves together DevOps and Security to master the force called DevSecOps. We explain how to assemble Red Hat products and our security ecosystem partners to aid in your journey to deploying a comprehensive DevSecOps solution.

Application Analysis defined

“Shift-left” is an often-used security marketing term that means adding security controls earlier in the DevOps life cycle. A large portion of those security controls falls under application analysis. 

The goal is to employ more secure coding practices and find security issues during development and build, where they cost much less to resolve than in production. The following security methods make up our application analysis category and dominate the left side of a DevOps life cycle:

  • Static Application Security Testing (SAST) analyzes source code to find security vulnerabilities or weaknesses.  In a typical SAST scan report for web applications, you will see vulnerabilities like SQL injections or Cross-Site Scripting.  Take a look at the OWASP Top 10, which provides an example set of vulnerabilities that you may see is SAST scans on web applications.

  • Software Composition Analysis (SCA) analyzes the third-party packages which are dependencies in applications (OWASP A9). SCA tools typically detect vulnerabilities, open source licensing risk and operational risk such as the age of a version and the community health of a project.

  • Interactive Application Security Testing (IAST) is a relatively newer testing technology under the dynamic testing category that monitors running applications and their runtimes through software instrumentation or agents.  IAST can help identify vulnerabilities and verify they are exploitable.

  • Dynamic Application Security Testing (DAST), also known as black box testing, identifies vulnerabilities through simulated attacks on a running application. When you hear the terms "penetration testing" or "fuzz testing," it usually means DAST.

  • Configuration Management is the analysis and management of application and infrastructure configurations in DevOps. While this method may seem to expand outside of application analysis, GitOps principles model application development for Kubernetes clusters and more and more application developers are becoming experts in configuration management. You may also hear Infrastructure as Code, or Policy as Code, and Everything as Code, which are all part of configuration management.

  • Image Risk is any risk associated with a container image outside of vulnerabilities in packages, which is covered by SCA above. This includes things like embedded secrets, bad configurations, malware, or images that are not trusted.  The reason this security method is separated from SCA is due to how each method is integrated in the DevOps life cycle—some security vendors only do SCA, but some do both.

Application analysis integrated in DevSecOps

As seen in the DevSecOps framework below, application analysis integrations are typically found on the left side of the DevSecOps life cycle. The table that follows details some, but not all, of the common integrations to consider for application analysis. 

application analysis devsecops

Integration Point

Description

Integrated development environment (IDE)

As you are writing code, SCA and SAST IDE plugins provide the ability to analyze your application code and third-party dependencies.  Although these integrations may not find all issues with the application (the build provides more context), they make up a critical function in DevOps that accelerates application development since the majority of code issues can be resolved before you attempt to break the build.

Source Code Management (SCM)

Various types of SAST and SCA integrations exist for SCM, usually as an automated analysis during some type of commit before the build. Depending on the environment, these integrations may be more work than needed. For example, if SAST and SCA are integrated in the IDE and the build runs at every commit, a static analysis SCM integration becomes redundant.  Also, it should be noted that for an effective SCA SCM integration, the application either needs to include a declarative dependency manifest (i.e., package.json for Node.js) or a build needs to occur to pull down the correct dependencies.

Configuration Management, on the other hand, is a key integration point with SCM because this is the foundation of GitOps. By using Git for infrastructure configs, you can help ensure stronger security guarantees and reduce the attack surface through the principle of least privilege and the ability to sign and track authorship of OpenShift configs.

Build Automation 

Herein lies the critical integration point with application analysis. Look to integrate most application analysis methods in the build, and add gates to critical issues identified. If possible, only execute specific scans when appropriate.  For example, you would not want to run a full SAST scan on every build.  

Depending on the type of application, IAST may be a good alternative to black box DAST testing. However, both require some type of interaction with the running application—either manual or automated. 

While new analysis techniques have surfaced with Dockerfiles in SCMs, this is the first step where you will have a chance to analyze the full container image you plan to deploy with your application. Images may contain hundreds of vulnerabilities, so an important cultural consideration is risk tolerance in order not to slow your DevOps down.

Binary Repository

Binary repository SCA integration can be a good way to speed up development through automated SCA scans of third-party dependencies before they end up in a build. Dependency blocking features and “golden repositories” are useful mechanisms to control security issues with dependencies. However, the issues should be known to the developer in some fashion (e.g., IDE plug-ins) before the application goes into the build, or you will risk a good amount of builds breaking and causing DevOps slowness.

Container Registry

As mentioned above, SCA and Image Risk are separate methods due to vendor capabilities as well as their separate integrations in the DevOps life cycle. This reasoning still holds true in the case of the container registry integrations. Some vendors provide only SCA capabilities for container images, and other vendors provide both SCA and Image Risk. 

Typically, these integrations are either embedded in the registry and provide results in the UI, or vendors support registries through something like a CLI, which typically pulls down the image and scans it in an exported tar format.

Container Orchestration 

Use SCA integrations during container orchestration to provide an inventory of what container images are running in your cluster, which then can be used to monitor and alert on future published security vulnerabilities.

All image risk, like embedded secrets and untrusted images, should be vetted by this point during the build or in the container registry. However, image risk data can be used in admission control for runtime security methods.

Cluster

Configuration management integrations in the running cluster include GitOps tools that monitor current versus desired state—and, in some use cases, automate to that desired state.  Runtime analysis tools also provide Kubernetes config monitoring to help ensure policies are met.

DAST integrations at the running cluster level are primarily found in testing or staging environments. You will find DAST scans in production. However, the use cases need to be carefully determined and architected. For example, responses to a security breach that can not be reproduced in a test environment.  A DAST production integration also needs to be lightweight, but at that point, this functionality would fit better in the Runtime Analysis category.

Enhance and extend application analysis with Red Hat partners

Combining Red Hat OpenShift Container Platform application analysis features with Red Hat’s certified Ecosystem Security Partners can help your organization's DevSecOps practice.  If you are looking to enhance and extend Red Hat’s security capabilities in application analysis, take a look at the following Red Hat Partners:

For more information, visit "Modernize and secure applications with DevSecOps," or begin your discussion with us on enhancing container security and adopting DevSecOps.


About the author

Dave Meurer currently serves as a Principal Solution Architect on the Red Hat Global Partner Security ISV team, where he owns technical relationships and evangelism with security independent software vendor partners of Red Hat. Before joining Red Hat, he spent nine years in the Application Security industry with Synopsys and Black Duck, where he served in similar roles as the director of technical alliances and sales engineering.

Read full bio