When I wrote WTF is ASPM, I was really just asking for the complete application security solution I had been writing for for years. In that article, I defined ASPM as a combination of vulnerability management tools, but more importantly, 8 different kinds of scanners. Uniting these traditional scanners into a single place continues to grow in importance, as managing 8 scanners per repo becomes more and more unrealistic for organizations.
Cycode separates these scanning capabilities into the buckets of pipeline security, application security testing, and posture management via third party vulnerability aggregation. I agree that these segmentations help make sense of the overall argument: one tool to do all of the scanning you need to protect applications, manage application vulnerabilities, and most importantly, get things fixed. Due to emphasis on testing, pipeline security is a frequently overlooked component, and can be thought of as the security of your source code manager itself, as well as your deployment pipelines.
Over the next few articles we’ll use a real world example to talk about the importance of each of these scanning capabilities, my insecure-kubernetes-repo, which mirrors how many real world repos are structured with common misconfigurations. This repo includes some code, pipelines, terraform, and everything that’s common to real world apps.
In this article, we’ll start by addressing the 4 segments of pipeline security, or what I called “SDLC” scanning in my article: Secrets Detection, CI/CD Security, Source Code Leakage, and Build Integrity.
Secrets Detection
Secrets detection is a common feature that varies drastically in maturity between companies. Some secret detection works based on simple regex, others use AI, and some have other contextual analysis. These all have different pros and cons, but these scanners exist to alert developers when they have accidentally hard coded a credential into their code.
Here’s a couple of examples from my repo that help illustrate these points:
- Hardcoded access keys in the python application
aws_access_key_id = 'AKIA2JAPX77RGLB664VE' aws_secret = 'v5xpjkwYoy45fGKFSMajSn+sqs22WI2niacX9y05'
- Hardcoded access keys in the helm chart:
spec: containers: - name: {{ .Values.insecureApp.appName }} image: "{{ .Values.insecureApp.image.repository }}:{{ .Values.insecureApp.image.tag}}" env: - name: AWS_ACCESS_KEY_ID value: AKIA2JAPX77RGLB664VE - name: AWS_SECRET_ACCESS_KEY value: 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
Using access keys in this way is a well known malpractice; however, it happens frequently in real world applications. Most of the time, giant production applications start as small test applications, where developers just hand jam a credential to get things working locally. After all, who cares about exposing a public key to a database with no data in it?
Over time, these applications become production, and it’s important to have robust coverage across your application files and commit history to look for secrets that may have been forgotten about. One especially frequent issue is developers noticing a secret, deleting it, and pushing up a new commit; however, doing this leaves the secret in the commit history, where it’s trivially discovered by attackers.
Any file can contain a secret, so it’s important that your scanner just checks all of them at once. Secret scanning is really a cornerstone capability for SDLC scanning, and usually one of the first pieces of an ASPM that teams implement.
CI/CD Security
Beyond secret scanning and the numerous types of scanners out there, many companies overlook the secure configuration of their SCM itself. Developer permissions can quickly get complicated – as layers of MFA, pipeline access, approver groups, and access to sensitive environment variables become difficult to track manually.
Typically two compliance requirements drive this demand:
- User access reviews
- Code reviews
Beyond these simple needs, CI/CD security quickly expands outside of permissions to securing the pipeline configuration itself. Pipelines are just containers being told what to do, so they have the same security vulnerabilities as applications themselves. This is another frequently overlooked area of security, as pipeline configurations can give attackers access to sensitive information and artifacts that allow for Solarwinds-like attacks.
Source Code Leakage
Like managing permissions, trying to track a mixture of public and private code projects is another challenge for large organizations who maintain public and private repositories. Code DLP is a real challenge for CISO’s, as developers are constantly interacting with code in different ways that may or may not be suspicious.
Because ASPM providers are hooked into SCM’s at a high level, they’re able to baseline and look for issues from common misconfigurations to intentional exfiltration by employees.This is also a general visibility issue, as CISO’s have little ability to detect and audit where their code is going. ASPMs are able to detect both anomalous developer access trends, and what tools have access to what repositories. Instead of manually tracking this as a lagging compliance requirement, ASPMs allow teams to actually get visibility into what has access to what code.
Moreover, ASPMs can identify patterns indicative of potential leaks. For example, a sudden spike in the volume of code being copied to external repositories or unusual access times by developers can trigger alerts for further investigation. This proactive approach ensures that any anomalies are detected and addressed promptly, reducing the risk of sensitive information being exposed.
Supply Chain Integrity
One major differentiator for Cycode is having an agent – Cimon – that can both detect build time attacks, and be used for SLSA attestation. On build time attacks, pipelines are typically blind to security teams. When cloud-hosted, companies get zero visibility into what’s happening inside of them – a challenge because they’re typically incredibly permissioned workloads. When self-hosted, the problem persists as endpoint protections aren’t really built for security.
Cimon offers a secure actions template that uses eBPF to secure the pipeline from malicious activity, as well as offering easy artifact integrity checking for SLSA compliance. These features are why I generally consider supply chain security a subset of ASPM more holistically.
Whether we like it or not, formal supply chain tracking, like SLSA (Supply-chain Levels for Software Artifacts) is growing in adoption. SLSA provides a framework for ensuring that software artifacts are verifiable and trustworthy. SLSA helps organizations share the security and integrity of their software development processes and is growing in regulated industries.
Conclusion
In this article, we’ve considered four areas essential to a comprehensive ASPM strategy: Secrets Detection, CI/CD Security, Source Code Leakage, and Supply Chain Integrity. Each of these areas presents unique challenges and requires specific tools and methodologies to address effectively. By leveraging a Complete ASPM solution like Cycode, organizations can unify their security efforts by avoiding implementing numerous different offerings across their stacks. Tools in this category provide their own scanning across the SDLC lifecycle, while integrating with existing solutions to provide complete code to cloud coverage.
