For many enterprises, application modernization — the overall transition from monoliths to cloud native, microservices architectures — presents an opportunity to evaluate improvements across the entire application development life cycle. In recent years, the exploding popularity of Kubernetes has seen significant adoption of DevOps practices and platforms, enabling engineering to release new applications weekly, daily or even faster.
However, these same improvements and processes, combined with progressively more complex and expansive microservices applications, have introduced a need for more visibility into the software development life cycle (SDLC) where application security teams are struggling to keep up with a sharp increase in security, privacy and compliance risks. According to the Red Hat State of Kubernetes Security Report, security concerns have resulted in many enterprises delaying the deployment of Kubernetes applications into production, with 94% of respondents experiencing at least one security incident in their Kubernetes environments in the past 12 months.
Many enterprises fail to implement and practice DevSecOps simply due to the operational challenges of bridging the gap between software development and security. However, as companies begin to mature and “shift left,” developers are being pressured to extract meaningful and actionable insights in the early stages of software development. For many enterprises, existing approaches to application security are often immature and reactive. Many vulnerabilities and security risks are going undiscovered late into the development process, leading to untimely delays and potential breaches as engineering is expected to prioritize new feature development against addressing security risks.
In recent years, next-generation application monitoring platforms have started to introduce “continuous observability” as a way to bring comprehensive visibility into every stage of the application life cycle. Ideally, continuous observability should enable organizations to continually and proactively monitor applications to understand what is slow or broken, as well as to quickly identify potential improvements to performance and stability. Unfortunately, many observability tools are not designed to address the unique requirements present in application security.
Moving forward, continuous AppSec observability is quickly becoming the next stage of DevSecOps maturity for many enterprises to achieve during their digital transformation to cloud native applications. By observing billions of live telemetry events in every thread/process/container, continuous AppSec observability can help developers, QA and security teams identify supply chain risks, system call risks, data risks and behavior risks during runtime, before the application transitions from test and staging into production. Ultimately, the goal is to “start left,” with security becoming a fully integrated part of the CI/CD pipeline, where vulnerabilities are observed in a running application.
Traditional legacy application security tools, such as static application security testing (SAST) and software composition analysis (SCA), have lacked visibility into application runtime, resulting in long, complicated reports with unnecessarily high alert volume and false positives. This “noise” contributes to the overwhelming feeling of “alert fatigue” preventing engineers from quickly and accurately prioritizing and triaging issues. In addition, the vast amount of information collected on software components — some never even loaded during runtime — can potentially affect an organization’s ability to create an accurate and refined software bill of materials (SBOM) for President Biden’s Executive Order on Improving the Nation’s Cybersecurity.
Introducing continuous AppSec observability can also enhance other AppSec tools, such as DAST (dynamic application security testing) and CIS (container image scanning), by providing them a view “behind the curtain” of the running application. Whether you are exercising the application to discover Open Web Application Security Project (OWASP) vulnerabilities or are using a container scanner during the build process to produce an exhaustive report of the application’s dependencies and images, the goal of continuous AppSec observability should be to enhance your findings with deeper, “semantically” richer insights.
With more enterprises looking to application modernization to protect investments and take advantage of infrastructure and software advancements, developers and application security professionals should be evaluating next-generation security platforms that:
- Address the needs of Dev, QA and AppSec without introducing significant operational overhead or complexity to the DevSecOps pipeline. This includes finding something that provides valuable insights without requiring a code change.
- Work with any application, regardless of the language, whether it’s running in a container, virtual machine or in a Kubernetes cluster.
- Complement existing tools in the pipeline, such as SAST, SCA, DAST and CIS by providing real-time visibility into the running application during functional and security testing.
- Provide engineering with a prioritized and refined list of vulnerabilities and alerts per application by highlighting which components are used at runtime and, if possible, which functions and classpaths are called.
At the end of the day, in order to reach DevSecOps maturity, enterprises must make continuous AppSec observability a part of the CI/CD pipeline to secure code quickly and at the source. This enables engineering leadership to accelerate productivity and decrease mean time to remediate (MTTR) security and compliance risks pre-production. All while empowering the application security team to establish guardrails, prioritize alerts and abate security risks before release.
To learn more about DevOps and other cloud native technologies, consider coming to KubeCon+CloudNativeCon North America 2021 on Oct. 11-15.
Featured image via Pixabay.