devopsy.kinsta.cloud

Tag: DAST

Shift Left Security: 4 Automated Security Gates in GitHub Actions
A security researcher filed a report against our Node.js API two years ago. The vulnerability was prototype pollution in an npm package we had been shipping for eight months. The fix took about 20 minutes. The internal review to figure out how it got through took two days.

The package had a known CVE. It had been sitting in the NVD for months before we found it. Our CI never checked. Code review didn’t catch it. The researcher did.

There’s a stat from IBM’s Cost of a Data Breach 2024 report that I keep referencing when this comes up: The average breach costs $4.88 million. Teams running DevSecOps practices save $1.68 million from that cost on average. The number I actually find more useful is smaller. A vulnerability caught in CI costs about $80 to fix. Caught in production, the same costs $7,600.

That gap is why this article exists. Four automated security gates wired into GitHub Actions, running on every push and pull request — none of them require an enterprise license:
- Gate 1: Dependency scanning — finds CVEs in your npm packages before they ship.
- Gate 2: Container image scanning — finds CVEs in your Docker base image OS packages.
- Gate 3: Static analysis (SAST) — finds code-level vulnerabilities such as SQL injection and hardcoded secrets.
- Gate 4: Dynamic scanning (DAST) — finds runtime vulnerabilities in a running instance of your app.
Wired together, the pipeline looks like this:

Pull Request / Push to main

│

▼

┌──────────────────────────────────────────────────────┐

│ GitHub Actions Pipeline │

│ │

│ Gate 1: Dependency Scan Gate 2: Image Scan │

│ (npm audit + Snyk) (Trivy) │

│ Finds: vulnerable packages Finds: OS + pkg CVEs│

│ ❌ CRITICAL → fail build ❌ CRITICAL → fail │

│ │

│ Gate 3: Static Analysis Gate 4: DAST │

│ (CodeQL) (OWASP ZAP Baseline)│

│ Finds: SQL injection, XSS, Finds: runtime vulns│

│ hardcoded secrets in running app │

│ ❌ High severity → fail ❌ Alerts → report │

│ │

│ ✅ All gates pass → merge allowed / deploy │

└──────────────────────────────────────────────────────┘

Gates 1 through 3 run in parallel on every push. Gate 4 only starts after all three pass. It boots the app and probes it live.

Prerequisites

Docker needs to be installed locally before you start. Most of the local testing this article highlights relies on it. The Snyk step needs a free account at snyk.io, but npm audit alone covers the basics if you’d rather not sign up. One other thing upfront: CodeQL runs free on public repositories; no paid GitHub plan is needed.

The sample app used throughout this article is an Express API with a Dockerfile and docker-compose.yml. The full code is on GitHub at github-actions-security-gates.

Gate 1: Dependency Scanning With Npm Audit and Snyk

Recently, I ran npm install on a fresh Express app. It pulled in 847 packages. I explicitly chose maybe 12 of them. The rest came along for the ride. Each one was a potential CVE.

Both tools scan the same dependency tree but do different things with what they find. npm audit catches what Node knows about and reports severity. Snyk goes further. The last time I ran it on a project, it surfaced issues npm audit missed, and gave me the exact upgrade version for each one, flagging which jumps would break the API. That detail cuts debug time significantly.

Drop this in .github/workflows/gate-1-dependency-scan.yml:

name: Gate 1 — Dependency Scan

on:

push:

branches: [main]

pull_request:

branches: [main]

jobs:

dependency-scan:

runs-on: ubuntu-latest

steps:

- name: Checkout code

uses: actions/checkout@v4

- name: Set up Node.js

uses: actions/setup-node@v4

with:

node-version: '20'

cache: 'npm'

- name: Install dependencies

run: npm ci

- name: npm audit

run: npm audit --audit-level=high

- name: Snyk dependency scan

uses: snyk/actions/node@v1.4.0

continue-on-error: false

env:

SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

with:

args: --severity-threshold=high

The --audit-level=high flag in npm audit means the job only fails on high and critical vulnerabilities, not on every minor advisory. Without this flag, most real codebases will fail immediately on low-severity issues that have no fix and no meaningful risk.

Snyk adds upgrade paths. When something gets flagged, the report shows which version resolves it and whether the jump is safe. I’ve had engineers close a failing PR in five minutes with that information. Without it, they’re opening changelogs and guessing.

Getting SNYK_TOKEN Into GitHub

Sign up at snyk.io, then go to your personal account settings at https://app.snyk.io/account. The Auth Token is there — not on the Organization Settings page, which only has the org API key. Copy it, then add it to your repo at Settings → Secrets and variables → Actions → New repository secret. Name it SNYK_TOKEN. That’s the exact name the workflow expects.

Handling False Positives With a `.snyk` Ignore File

Do not turn off a gate because one advisory is a false positive. Document the exception instead:

# .snyk

version: v1.25.0

ignore:

SNYK-JS-INFLIGHT-6095116:

- '*':

reason: No upstream fix available. Package used only in dev dependencies, not shipped to production.

expires: '2027-01-01T00:00:00.000Z'

created: '2026-07-01T00:00:00.000Z'

Three fields matter: reason explains the decision, expires forces a review date and created creates an audit trail. If a SOC 2 auditor asks why you suppressed a CVE, this file is your answer.

Gate 2: Container Image Scanning With Trivy

Dependency scanning only looks at your npm packages. Your Docker base image carries its own OS-level packages: glibc, curl, openssl. Those have CVEs too.

Trivy scans the entire container image: OS packages, language packages and configuration issues. It runs in CI before the image ever touches a registry.

Create .github/workflows/gate-2-image-scan.yml:

name: Gate 2 — Container Image Scan

on:

push:

branches: [main]

pull_request:

branches: [main]

jobs:

image-scan:

runs-on: ubuntu-latest

steps:

- name: Checkout code

uses: actions/checkout@v4

- name: Build Docker image

run: docker build -t myapp:${{ github.sha }} .

- name: Scan image with Trivy

uses: aquasecurity/trivy-action@0.28.0

with:

image-ref: myapp:${{ github.sha }}

format: table

exit-code: '1'

severity: 'CRITICAL,HIGH'

ignore-unfixed: true

Two decisions here are worth explaining.

First, ignore-unfixed: true. Some CVEs have no patch available. If you leave this out, your build fails on vulnerabilities that have no fix. It blocks your team with no action they can take. This flag filters those out. You still see them in the report; they just don’t block the build.

Second, scan before pushing to the registry. A lot of pipelines build the image, push it, then scan. That means a vulnerable image is sitting in your registry for however long the scan takes. Build it, scan it, push only if clean.

Suppressing Known False Positives With `.trivyignore`

# .trivyignore

# CVE-2023-44487 HTTP/2 Rapid Reset - handled at load balancer (nginx rate limits + conn caps)

# owner: zia.ullah@valueadd.se | next review: 2027-01-01

CVE-2023-44487

Same principle as the Snyk ignore file: Document the reason, add a review date.

Gate 3: Static Analysis With CodeQL

Dependency scanning and image scanning look at what you install. CodeQL looks at what you write.

It traces data flows through your code. SQL injection, where input from a route param reaches a database call without sanitization; XSS, where a user-controlled string ends up in an HTML response; hardcoded secrets buried in config files; path traversal — these aren’t hypothetical patterns; they’re the vulnerability classes in most breach reports.

Create .github/workflows/gate-3-codeql.yml:

name: Gate 3 — Static Analysis (CodeQL)

on:

push:

branches: [main]

pull_request:

branches: [main]

schedule:

- cron: '0 6 * * 1' # weekly scan on Monday at 6am

jobs:

static-analysis:

runs-on: ubuntu-latest

permissions:

actions: read

contents: read

security-events: write

steps:

- name: Checkout code

uses: actions/checkout@v4

- name: Initialize CodeQL

uses: github/codeql-action/init@v3

with:

languages: javascript, typescript

queries: security-extended

- name: Autobuild

uses: github/codeql-action/autobuild@v3

- name: Perform CodeQL Analysis

uses: github/codeql-action/analyze@v3

with:

category: "/language:javascript"

The queries: security-extended line matters. The default query set catches the most obvious issues. The extended set adds more SQL injection patterns, SSRF detection and stricter taint tracking. For a production application, use extended.

The security-events: write permission lets CodeQL post results to GitHub’s Security tab. You’ll see findings there even when the build passes.

CodeQL is free for public repositories. For private repositories, it requires GitHub Advanced Security. If you’re on a private repo without GHAS, Semgrep OSS is a free alternative:

- name: Semgrep scan

uses: returntocorp/semgrep-action@v1

with:

config: p/owasp-top-ten

Gate 4: DAST With OWASP ZAP

The first three gates analyze artifacts: Package manifests, container layers, source code. Gate 4 does something different. It actually starts your application and attacks it.

Gate 4 was the one I was most curious about when I first set this up. It actually boots the app and fires real HTTP requests at it. What comes back tells you things the source code never could. A 500 where the app should return a 400. Missing headers on endpoints that aren’t configured. Open redirects. None of that shows up in a static scan.

The OWASP ZAP baseline scan is fast enough for CI. It runs passive checks. No brute-forcing, no fuzzing. It observes and probes. Most pipelines complete it in under three minutes.

Create .github/workflows/gate-4-dast.yml:

name: Gate 4 — DAST (OWASP ZAP)

on:

push:

branches: [main]

pull_request:

branches: [main]

jobs:

dast:

runs-on: ubuntu-latest

steps:

- name: Checkout code

uses: actions/checkout@v4

- name: Start application

run: |

docker compose up -d

sleep 15

- name: Wait for app to be ready

run: |

for i in {1..10}; do

curl -s http://localhost:3000/health && break

echo "Waiting for app..."

sleep 3

done

- name: ZAP Baseline Scan

uses: zaproxy/action-baseline@v0.10.0

with:

target: 'http://localhost:3000'

rules_file_name: '.zap/rules.tsv'

fail_action: warn

- name: Stop application

if: always()

run: docker compose down

fail_action: warn is the right default for DAST. ZAP has a higher false-positive rate than the other gates. On the first run against a JSON API, you’ll see alerts for missing CSP headers, missing HSTS and permissions policy. Most of those are intentional. Setting it to warn keeps the findings visible in the job output without blocking the build. Review the ZAP report on a schedule; don’t let warnings pile up unreviewed.

Cutting ZAP Noise With `.zap/rules.tsv`

10021IGNORE(Strict-Transport-Security not set on HTTP - intentional on local non-TLS endpoint)

10038IGNORE(Content Security Policy not set - handled at reverse proxy level)

The rule IDs are in the ZAP docs at zaproxy.org/docs/alerts. I kept that page open during the first few scans. 10038 is the CSP one. 10035 is HSTS. After looking them up a couple of times, you stop needing to.

Running All Four Gates in One Workflow

Four separate workflow files work fine for learning, but in practice, I merge them into one. The first three jobs run in parallel. Gate 4 holds until all three finish: No point scanning a live app if the code already has a known SQL injection in it.

Create .github/workflows/security-gates.yml:

name: Security Gates

on:

push:

branches: [main]

pull_request:

branches: [main]

jobs:

dependency-scan:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- uses: actions/setup-node@v4

with:

node-version: '20'

cache: 'npm'

- run: npm ci

- run: npm audit --audit-level=high

- uses: snyk/actions/node@v1.4.0

continue-on-error: false

env:

SNYK_TOKEN: ${{ secrets.SNYK_TOKEN }}

with:

args: --severity-threshold=high

image-scan:

runs-on: ubuntu-latest

steps:

- uses: actions/checkout@v4

- run: docker build -t myapp:${{ github.sha }} .

- uses: aquasecurity/trivy-action@0.28.0

with:

image-ref: myapp:${{ github.sha }}

format: table

exit-code: '1'

severity: 'CRITICAL,HIGH'

ignore-unfixed: true

static-analysis:

runs-on: ubuntu-latest

permissions:

actions: read

contents: read

security-events: write

steps:

- uses: actions/checkout@v4

- uses: github/codeql-action/init@v3

with:

languages: javascript, typescript

queries: security-extended

- uses: github/codeql-action/autobuild@v3

- uses: github/codeql-action/analyze@v3

with:

category: "/language:javascript"

dast:

runs-on: ubuntu-latest

needs: [dependency-scan, image-scan, static-analysis]

steps:

- uses: actions/checkout@v4

- name: Start application

run: |

docker compose up -d

sleep 15

- name: Wait for health check

run: |

for i in {1..10}; do

curl -s http://localhost:3000/health && break

sleep 3

done

- uses: zaproxy/action-baseline@v0.10.0

with:

target: 'http://localhost:3000'

rules_file_name: '.zap/rules.tsv'

fail_action: warn

- name: Stop application

if: always()

run: docker compose down

The needs: [dependency-scan, image-scan, static-analysis] line is the key. Gate 4 only starts if the first three complete without error.

Handling False Positives Without Turning Off Gates

Every team that installs security tooling eventually hits a false positive and considers disabling the rule. I’ve seen it happen within the first week on most teams. The right response is to suppress it with documentation, not remove it.

Each tool has its own mechanism.

Snyk uses .snyk with expiry dates. A suppression that never expires is forgotten. Set an expiry. When the date passes, the build fails again and forces a review.

Trivy uses .trivyignore with CVE IDs and comments. One CVE per line, one comment explaining why.

ZAP uses .zap/rules.tsv with rule IDs. The ZAP documentation lists every rule ID and what it detects. Rule 10038 is CSP. Rule 10035 is HSTS. Once you know the IDs, suppression is a one-liner.

CodeQL suppressions go in the code itself:

// codeql[js/sql-injection]

const result = await db.query(query);

The codeql comment tells CodeQL to ignore the finding on that line. Use it rarely, document why.

If a SOC 2 auditor asks about your suppression decisions, these files are your evidence. They show that you evaluated each finding, made a documented decision and set a review date. That’s more defensible than having no suppressions and no findings because the tool is turned off.

Troubleshooting

These are real issues that surfaced while building and testing this pipeline, not edge cases. Each one will stop your build until you know the fix.

ZAP Docker Image Not Found: `owasp/zap2docker-stable`

This image was deprecated and removed from Docker Hub. Any article or Stack Overflow post referencing it is out of date. The correct image is:

ghcr.io/zaproxy/zaproxy:stable

Update your local test command and any workflow files that reference the old image name. The GitHub Container Registry image is maintained by the ZAP project team and receives regular updates.

Healthcheck Shows `(unhealthy)` — Curl: Command Not Found

node:20-slim is a minimal Debian image. It does not include curl. A healthcheck that uses curl will silently fail and mark the container as unhealthy, which blocks ZAP from scanning a ready application.

Switch the healthcheck to use Node’s built-in http module instead:

healthcheck:

test: ["CMD", "node", "-e", "require('http').get('http://localhost:3000/health', r => process.exit(r.statusCode === 200 ? 0 : 1))"]

interval: 10s

timeout: 5s

retries: 3

start_period: 10s

Node’s http module ships with every Node image. No extra packages, no install step. Works on alpine, slim and full Debian variants.

Docker Compose Fails With “port is Already Allocated”

This one caught me the first time I ran the local setup. I had npm start running in another terminal, so docker compose couldn’t bind port 3000. It also happens when a container from a previous run is still sitting there — docker ps will show it.

Before running docker compose, stop anything using the port:

npx kill-port 3000

docker ps -a # check for running containers from other projects

docker stop <container-name>

If you see docker compose up succeed but the container exits immediately, the port conflict is the first thing to check.

ZAP Scan Fails With “Connection Refused” or Downloads With EOF Error

Two separate issues that look the same.

I hit this on the first local test. The container looked like it started fine, but ZAP couldn’t reach it. docker ps still showed (starting). The healthcheck needs to pass before ZAP can connect. If it’s stuck there, add more time to start_period in docker-compose.yml and try again.

The EOF error during the ZAP image download means the pull got cut off partway. Pull it separately first:

docker pull ghcr.io/zaproxy/zaproxy:stable

Then re-run your scan command. The cached layers will be used on the next attempt.

Snyk Returns 401 Unauthorized in GitHub Actions

It shows up as SNYK-0005 in the workflow logs. Usually, one of two things caused it.

First, the token location. Snyk has two types of keys: An Organization API key and a personal Auth Token. The GitHub Actions integration requires the personal Auth Token, not the org key. Get it from https://app.snyk.io/account under “Auth Token” — not from the Organization Settings page.

Second, the secret scope. The secret must be added to the specific repository where the workflow runs. Organization-level secrets are not automatically shared with all repositories. Go to the repository, then Settings → Secrets and variables → Actions → New repository secret. Name it SNYK_TOKEN.

Trivy Reports CVEs That Aren’t in Your Code

The first time I ran Trivy against this project, it flagged 18 findings. My application code had zero issues. Everything else came from two places: The Debian base image packages and npm’s own bundled toolchain. Trivy scans the whole container, not just what you wrote.

Debian packages such as libgnutls30 and libcap2 come bundled with node:20-slim. In our case, most of those CVEs were DTLS vulnerabilities in a library our HTTP-only API never touches. They flag, but there’s no exploitable path.

The npm ones took me a minute to understand. The path gave it away — /usr/local/lib/node_modules/npm/node_modules/. That’s not your app. That’s npm’s own private dependencies: tar, minimatch, cross-spawn. That directory is npm eating its own dog food — packages npm uses internally when it installs things. Once the build is done and the container starts, nothing calls that code again.

Handle both with .trivyignore. Document each suppression:

# .trivyignore

# libgnutls30 — DTLS vulnerability, not exploitable in this HTTP-only API

# Fixed version available in Debian but not yet in node:20-slim

# Approved: your.email@company.com | Review: 2027-01-01

CVE-2026-33845

# tar (npm internal) — npm's own toolchain, not in runtime dependencies

# Only used during npm install, not exposed in the running container

CVE-2026-23745

The pattern is the same as .snyk: Reason, owner, review date.

Node_modules Committed to Git — Missing .gitignore

If you initialize a repository and run npm install before creating a .gitignore, Git will track node_modules and .env. A push with node_modules sends thousands of files to GitHub and can expose a committed .env file.

Add this before you push anything:

node_modules/

.env

*.log

If you pushed before adding .gitignore, node_modules is already in Git’s history. You need to untrack it without deleting it from the disk:

git rm -r --cached node_modules

git rm --cached .env

git commit -m "Remove tracked files that should be ignored"

CodeQL Fails With “No Source Code Was Seen During the Build”

I hit this on a project where the build script wasn’t the default. CodeQL’s autobuild guesses your build command — it gets it right most of the time, but not always. When it misses, swap it out for an explicit run step:

- name: Manual build

run: npm ci && npm run build

ZAP Scan Fails Because the Application Won’t Start

The sleep timer in the workflow might not be long enough for your app to initialize. Increase sleep 15 to sleep 30 or use the healthcheck loop shown in the full workflow above. If the app needs environment variables to start, pass them with a .env.ci file in the repository (with non-production values).

Wrapping Up

Four gates; none requiring an enterprise license — each one catches a different class of vulnerability at the point where it’s cheapest to fix.

The math isn’t complicated. A critical CVE found in CI takes minutes to fix. The same CVE found after a breach starts the clock on $4.88 million in average costs. The tooling here is free. The GitHub Actions minutes are cheap. The only thing the pipeline costs is the time required to set it up. Once.

One thing teams usually don’t anticipate: False-positive management is ongoing work. You will suppress some findings. You will review them when the expiry dates pass. That’s the point. Security tooling that runs without maintenance is security tooling that nobody trusts.

The complete working example — including the Node.js app, Dockerfile, docker compose and all four workflow files — is available at github-actions-security-gates.
August 4, 2026
Checkmarx Acquisition of Tromzo Accelerates Plan to Apply AI to Application Security

Checkmarx has revamped its strategy for infusing artificial intelligence (AI) agents into DevSecOps workflows following its acquisition of Tromzo, a provider of an application security posture management platform (ASPM).

Earlier this year, Checkmarx committed to building three classes of AI agents within a Checkmarx Assist portfolio, starting with a Developer Assist tool that it developed. The other two Policy Assist Agent and Insight Assist Agent will now be based on AI agents developed by Tromzo to apply AI.

Ori Bendet, vice president of product management for Checkmarx, said in effect the acquisition of Tromzo accelerates the timeline the company had set for building a suite of AI agents that automate application security workflows across the entire software development lifecycle (SDLC). Checkmarx also gains a cybersecurity team that has already developed a lot of expertise when it comes to applying AI to application security, he added.

Tromzo CEO Harshil Parikh said that as a provider of an ASPM, Tromzo is already using AI to understand the unique attributes of a codebase. Whenever an issue is discovered, its AI agents will then surface code recommendations for fixing it. That approach eliminates the need for a developer to spend time researching the vulnerability and then building a patch, said Parikh.

That capability will soon be extended using data collected by the static application security testing (SAST), dynamic application security testing (DAST) and software composition analysis (SCA) tools developed by Checkmarx, noted Parikh.

The acquisition of Tromzo comes at a time when DevSecOps teams continue to struggle. A recent Checkmarx survey finds nearly all (98%) organizations have experienced a security breach attributable to vulnerable code, with 81% acknowledging their organization has shipped code with known vulnerabilities into production environments. More than a quarter of organizations (27%) experienced four or more breaches due to these vulnerabilities.

Roughly a third of respondents are resigned to additional incidents occurring in the next 18 months, with software supply chain compromise (35%) topping the list followed by a third-party vendor/partner security incident (35%), cloud infrastructure misconfiguration (34%), insider threat or privileged access misuse (33%) and application programming interface (API) security breach or business logic attack (32%).

As the pace at which applications are being developed in the age of AI continues to accelerate, many of these issues will only be further exacerbated. The only way DevSecOps teams will be able to keep pace is to rely more on AI to discover and remediate issues, many of which will be created by developers relying on AI coding tools that generate more flawed code than ever.

Hopefully, there will come a day soon when AI coding tools generate higher-quality code, but in the meantime, DevSecOps teams should prepare for the worst. Cybercriminals are now also adopting AI tools with an eye toward not only discovering more vulnerabilities but also creating the code needed to exploit them in a matter of minutes. As such, the number of zero-day vulnerabilities that DevSecOps teams will be required to remediate as quickly as possible is about to dramatically increase.

December 18, 2025
DAST is Broken, Not Dead. Dynamic Testing Must Evolve
For years, DAST was the go-to approach for identifying vulnerabilities in web applications. But let’s be honest, DAST has built up quite a bad reputation. If you have ever worked with traditional DAST solutions, you would know the pain:
- Slow and Disruptive: Scanning with DAST often feels like waiting for paint to dry —except, at the end of it, your engineers are bombarded with false positives which ultimately waste their time.
- Quality Issues: It is not just the slowness; it is the lack of depth. Traditional DAST tools are notorious for missing modern threats while flagging non-issues that don’t put applications at risk.
- Hated by Developers: The intrusive and unpredictable nature of DAST scans means engineers either schedule them reluctantly or, worse, don’t run them at all. In general, DAST tools are not integrated into developers’ processes, tools or pipelines.
The result? Security teams aren’t getting the feedback they need, and developers are too annoyed to engage in the process, leaving the entire attack surface exposed. That’s not a recipe for effective security.

DAST Scans Web Apps; But Modern Apps are API-Driven

Another major flaw? DAST is stuck in the past. Most traditional DAST tools were built to scan monolithic web applications, but modern applications are API-first, urging the need for API-focused solutions (see Application Security Hype cycle”, Gartner, 2024).

Whether it is traditional REST APIs, GraphQL or SOAP, let alone cutting-edge LLM APIs, today’s attack surface revolves around APIs, not just front-end websites. If your security testing tool isn’t designed for APIs, it is already outdated. Attackers certainly aren’t limiting themselves to outdated methodologies, so why should security teams?

Business Logic Vulnerabilities: The Blind Spot DAST Can’t See

The world of cybersecurity has evolved. Attackers today don’t just exploit generic security flaws; they go after business logic vulnerabilities — the loopholes within an application’s workflows that can be manipulated for fraud, privilege escalation or unauthorized access.

But here’s the problem: Traditional DAST tools don’t understand business logic. They scan applications blindly, looking for predefined patterns instead of understanding how the app is actually used. Modern security solutions need context-aware technology that understands the nuances of API interactions, application behavior and user roles to identify these sophisticated threats.

Future of Dynamic Testing: It is Time for an Overhaul

So, does this mean DAST is completely dead? Not quite. But it must evolve. Rebranding DAST isn’t about slapping a new label on the same old toolset — it is about demanding more from vendors and shifting the way we think about security testing. Here’s what that means in 2025:
1. DAST solutions must be API-first: Security testing tools must prioritize APIs, covering everything from traditional API endpoints to emerging API architectures.
1. Context-aware scanning is non-negotiable: Instead of blindly probing for vulnerabilities, security tools need to understand how an application functions and where logic-based weaknesses might exist.
1. Speed, accuracy and usability matter: If engineers hate using your tool, it won’t be used. Modern security testing must be fast, developer-friendly, integrated well into developer processes and minimize false positives.
Security teams today need more than a relic of the past. The era of traditional DAST is over, and the industry must move forward. The question isn’t whether DAST should change — it is whether security leaders and vendors are ready to embrace a modern, API-first, context-aware approach to security testing.
March 21, 2025
Security Across the SDLC

We’ve seen some interesting movements in the security space over the last couple of years. My focus is on application security, but one of the movements we’ve seen is the blurring of what is application and what is infrastructure security, so I do a fair amount of that also. And then, with the advent of WAAP, we have network security playing a role in AppSec… It’s a growing snowball.

I will start with the mandatory happy declaration that DevOps no longer treats security as an annoyance. While we’re well past that, I think the shock of the whole “security is a problem, not protection” mentality that DevOps started with is still hanging with us, and some still actively believe that. But at this point, we’re well on the “Security is part of the process” trail we should be on.

If you look at the top-level changes, static application security testing (SAST) vendors have grown to be development security, covering SAST, DAST, IAST, RASP and even a bit of data security. Meanwhile, load balancers and WAF slowly evolved into full-on web applications and API security that covers the production side with active protections for things like DDoS and DLP.

Likewise, we’ve seen this with the growth of cloud workload protection and how the entire digital architecture is being pulled into CSPM.

I’ve said it before – we’re in a consolidation phase. It looks like it will go even further than I thought, though. Now, we are starting to see an interesting development: WAAP vendors are starting to include some or all of DAST, SAST and RASP. Arguably, they always did some IAST because their focus was on runtime protection, but their emphasis is more on protection than test, so it will be interesting to see that bit expand also.

And all of this includes an inconvenient fact. We don’t have any more people to do security than we ever did; in fact, we have less. That’s part of the reason that we haven’t shoved security everywhere – there aren’t people to do it. In true DevOps fashion, we have distributed the work across other teams – Dev is right there where code security and API security start, so we’ve implemented SAST and DAST bits right into the IDE, for example. Or Ops has always done some amount of security, and we’ve just upped the amount. But they don’t magically have more time, either. I’m sure you are feeling it if you are a practitioner; almost all of us are. AI promises to help with that, and in security, it will likely deliver. Another thing I’ve pointed out before is that security is one space that really does stand to gain from generative AI – in helping make more secure code, in helping make all the permutations of tests, in making rules based upon observed data and more. The time-saving benefits will deliver, in my opinion. But it’s still a lot of work, and some of it is straight-up additional work because we weren’t doing things like container security a few years ago.

In the short term, if full SDLC security is applied, there will be more work. In the long term, the mega platform for security may well reduce this work as it limits notifications across tools. Maybe we should name the coming mega platform SecArch. Also in the long term, AI will help alleviate some of the load. Until then, buckle in. You’re not likely to get staff to cover new work. But it will be worth it. Just keep plugging along, and know when to say you just can’t add one more thing to the pile.

January 31, 2024
2024: The Year of Testing

Caveat: I currently cover DevOps – including test – and security – including the *AST. This does give me a viewpoint that others may not have, and also potentially gives me blinders that others may not have. I am not generally a predictor but a reader of direction. Proclamations like this are rare for me and are shorter-term/more tactical than the grab bag of predictions usually seen this time of year.

I was thinking about this one this morning; the direction of travel of traditional and security testing is very similar at the moment. We are seeing the vast complexity of the overall space and the rapid growth of automation come together to once again make all testing a topic worthy of consideration.

I loved test-driven development (TDD). I can’t speak for others, but RPC/API is just a cool way to implement centralized functionality, and TDD is almost mandatory to develop APIs and the clients that call them. There is no UI to distract or have separate requirements in API development; there is a stated function and correct or incorrect behavior. To a computer scientist, this is predictable beauty. TDD made it more than predictable—it made it a trail through the woods. “We know it needs to do X, Y and Z, with the only side effects being A,” can be detailed with tests to prove that is what it does, and then look to prove the “It doesn’t have other side effects” part. And you can do it all while developing—no need for dev/test iterations. Like any IT solution, it isn’t a great fit for everything, but even if it isn’t called TDD, it is nearly impossible to develop API-based solutions without some level of TDD.

The thing is, TDD is absolutely a developer’s tool. Developers and DevOps pretty much must use it to turn out usable APIs. The test team only has a use for a subset of those tests. Because if the dev team did it right, they passed all the TDD tests, and the test team’s role in that scenario is to look closely at what the developers might have missed. Integration is often beyond the control of an individual dev and/or API, for example, because many different clients may be integrating with it. Test teams, in a true TDD shop, fill the gaps with meaningful tests that evaluate the overall application quality.

Security testing—at least static application security testing (SAST) and increasingly dynamic application security testing (DAST)—are also becoming a core part of the development process. This is as it always should have been. It is far easier to fix a security flaw (or any flaw) at the design/early code stage than in a testing process after deployment. The quality of security testing inputs is also increasing, making it far more viable. And finally, the tools are being effectively integrated. Being a developer who did a lot of security work because we often needed it and had no one to do it, I will say I get a little rush about being told right in my IDE about the security risks in my code. I write, I see, I revise where necessary, and I turn out better code. All without having to pause for security or bang heads over policy.

To date, all this testing is separate, but I suspect, having vaguely the same location in the process of development, that testing will all occur together and the markets may even start to merge a bit—though merger of security testing and functional/performance testing tools is a bit of a stretch, it is more possible than in the past. In most orgs, even though developers have an increasing stake in both sets of testing, the target purchasers are still two different groups—security versus test—with different priorities. That’s why I think they aren’t likely to merge any time soon.

While AI in most technology spaces is currently experiencing the same level of FUD as XML, Java, JavaScript or low-code was in the past, all super-hyped tools in tech do have a sweet spot. Security and testing are in that sweet spot for AI. Both in test generation and in results evaluation, it does it better, faster and with more coverage while giving staff a concrete set of results to pore over and improve security posture and/or code quality. I cannot say loudly enough that in terms of enabling the steps in the SDLC that have suffered from a lack of resources and timeline to write, execute and evaluate tests, AI is a game-changer.

So, all of these things together mean that 2024 is a good time to take a hard look at your testing environment(s) and architecture, both traditional testing and security testing. Now that AI has made advanced automation a fact, it is time to consider implementing the level of testing we always knew we should have but never had the resources. Build it right into the build process and make it part of the organizational DNA—just like Agile is.

If you could hire a specialist who would paw through your code and give you a list of the 25 things you need to fix first, you would do it. That is, essentially, what modern testing tools are. They can do more tests, evaluate more issues and side effects and filter down to the “No—this is really important!” list without costing the team a ton of time.

And keep rocking it. We’re all sitting on bugs and vulnerabilities. I do hope we are way past denying that fact. Apps are big old complex monsters; these days, sometimes built from generations of technologies cobbled together. Of course they have issues. Even yours. So let’s take steps to clean it up, just a little bit. And keep clipping along.

December 6, 2023
Veracode Extends DAST Reach Left Toward Developers

Veracode this week launched a version of its automated dynamic application security testing (DAST) testing tool, dubbed DAST Essentials, that is designed to be embedded within an integrated development environment.

In addition, the company has made available a Veracode GitHub App that makes it possible to configure Veracode DAST tools to automatically scan code any time it is added to a repository.

Veracode already makes available a DAST tool that can be integrated with Veracode Fix, a tool that makes use of a large language model (LLM) curated by Veracode to apply artificial intelligence to surfacing recommendations to remediate vulnerabilities. Developers can then automatically update their source code or apply the recommended remediations as a patch using a pull request.

Brian Roche, chief product officer at Veracode, said in addition to embedding DAST capabilities into a DevSecOps workflow, DAST Essentials provides DevSecOps teams with the option to push scanning further left into integrated development environments (IDEs).

The overall goal is to automate code scanning and remediation across the entire software development life cycle. As part of that effort, Veracode will also be extending the integration of its DAST tools into additional software repositories, noted Roche.

It’s not clear whether AI will fully resolve software supply chain security concerns, but the one thing that is certain is the amount of code being generated is already starting to exceed the ability of DevSecOps teams to effectively manage. DAST Essentials provides a way to apply scanning at the front end of the application development process in the hopes that fewer issues will arise once code is merged with a build. However, given the number of issues that can arise, most organizations will also need to continuously scan builds as they are updated.

In the longer term, Veracode also plans to scan code after it’s been deployed in a production environment to enable DevSecOps teams to address zero-day vulnerabilities that are discovered after an application is deployed.

While a lot of DevSecOps progress has been made in recent years, there is still much work to be done. Developers still don’t scan code as frequently as they should, and there are still updates being made to codebases that occur outside of a DevSecOps workflow. However, as regulations for building and deploying software become more rigorous in the years ahead, it’s only a matter of time before automatically invoking code scans at multiple points of the software engineering process becomes mandatory.

In the meantime, DevSecOps teams will need to find ways to address application security issues in a way that causes the least amount of friction possible. Most developers have an appreciation for security, but far too many still view it as an obstacle to be overcome rather than a quality attribute that needs to be attained and maintained. However, those same developers will complain when cybersecurity teams discover potential vulnerabilities that a developer first must determine affect an application and then apply a patch as necessary. The challenge, as always, is finding a way to ensure application security without slowing down the pace of application development.

November 28, 2023
Shift Left With DAST: Dynamic Testing in the CI/CD Pipeline

Dynamic application security testing, or DAST, is a process used to evaluate an application’s security while it’s running rather than while it’s in a static state. This method involves simulating attacks on an application, identifying vulnerabilities and analyzing the responses. DAST focuses on the exposed HTTP and HTML interfaces of web-enabled applications, making it an excellent tool for spotting security vulnerabilities that may occur during an application’s active runtime.

DAST is a ‘black-box’ testing method, meaning it tests the application from the outside in—much like a potential attacker might. It doesn’t have access to the source code and instead focuses on the application as a whole rather than its individual components. This external perspective enables DAST to discover potential security threats that static testing methods might miss.

While DAST is an effective security testing tool, it becomes even more potent when paired with a shift left approach.

Understanding the Concept of ‘Shift Left’ in Software Testing

Shift left is a practice in software development where testing is conducted earlier in the life cycle—that is, it’s ‘shifted left’ on the project timeline. Traditionally, testing was seen as the last phase before the release of a software product. However, with the shift left approach, testing becomes an integral part of every stage of the development process from planning to deployment.

This approach has several advantages. It allows for the identification and resolution of issues earlier in the development process, reducing the cost and effort required to fix them later. It also encourages collaboration between developers and testers, fostering a more cohesive, efficient development environment.

Shift left is not just a testing strategy but a philosophy that promotes preventive measures over reactive solutions. It’s about building quality and security into software from the get-go, rather than tacking it on at the end.

DAST in the Context of Shift Left

Importance of DAST in Early Stages of Development

The integration of DAST in the early stages of development is crucial for several reasons. First, by conducting dynamic security testing from the onset, teams can identify vulnerabilities earlier, making them easier and less costly to fix. This proactive approach helps to prevent security issues from becoming ingrained in the code, which can lead to significant problems down the line.

Second, early integration of DAST encourages a security-focused mindset from the beginning of the project, promoting a culture of security within the team. This cultural shift is crucial in today’s cybersecurity climate, where threats are increasingly sophisticated, and the stakes are higher than ever.

How DAST Complements Other Testing Methods

DAST doesn’t replace other testing methods; rather, it complements them. While DAST focuses on external vulnerabilities, other testing methods like static application security testing (SAST) can target internal issues. By combining these methods, teams can achieve a more comprehensive view of their application’s security.

In a shift left approach, this combination of testing methods can be very powerful. By conducting these tests early and often, teams can ensure that both the external and internal aspects of their application are secure. This layered approach to security testing can help to catch any vulnerabilities that might otherwise slip through the cracks.

Incorporating DAST Into the CI/CD Pipeline

1. Understanding the Application Structure

Before we can integrate DAST into the CI/CD pipeline, it’s crucial to understand the structure of the application we’re working with. This involves understanding the layers of the application, the technologies used and the data flows. By analyzing the application’s architecture, you can identify the critical components that need more attention during the security testing phase.

Understanding the application structure is not just about knowing the technology stack. It’s also crucial to understand the business logic and the functionality of the application. This will allow you to create better test cases during the DAST process. Additionally, understanding the application structure will enable you to make better decisions when configuring the DAST tool, leading to more efficient and effective security testing.

Finally, understanding the application structure will help you prioritize the vulnerabilities found during the DAST process. Not all vulnerabilities are created equal; some might be more critical due to the data they expose or the potential damage they could cause to the application.

2. Configure the DAST Tool

The next step is to configure the DAST tool. This involves setting up the scanning parameters, defining the test cases, and tuning the tool to reduce false positives.

When configuring the DAST tool, it’s important to strike a balance between thoroughness and speed. You want the tool to be able to identify all potential vulnerabilities, but you also want the scanning process to be fast enough not to slow down the development process. This balance can be achieved by carefully selecting the scanning parameters and continuously tuning the tool based on the results of the scans.

Additionally, when configuring the DAST tool, you should consider the unique characteristics of your application. For example, if your application uses a specific technology or framework that is known to have certain vulnerabilities, you should ensure that the DAST tool is configured to test for these vulnerabilities. Similarly, if your application handles sensitive data, you should prioritize testing the components that process and store this data.

3. Integrating DAST Into the CI Pipeline

The next step is to integrate DAST into the CI pipeline. The CI pipeline is a sequence of steps that developers follow to merge their changes into the main codebase. By integrating DAST into this pipeline, we can ensure that every code change is automatically tested for security vulnerabilities.

Integrating DAST into the CI pipeline can be achieved using various tools and plugins. Most DAST tools provide APIs that allow you to automate the testing process. By using these APIs, you can trigger a DAST scan every time a new code change is pushed to the repository. This allows you to catch vulnerabilities early in the development process, reducing the cost and time needed to fix them.

However, integrating DAST into the CI pipeline is not a one-time task. It requires continuous monitoring and tuning to ensure that the testing process remains effective. You will need to update your DAST configurations as the application evolves, add new test cases as new features are developed, and fine-tune the testing process to reduce false positives.

4. Scan for Vulnerabilities

After integrating the DAST tool, you can start scanning for vulnerabilities. The scanning process involves executing the test cases defined during the configuration phase and identifying potential security issues in the application. Depending on the size and complexity of your application, this process can take from a few minutes to several hours.

During the scanning process, the DAST tool will interact with the application just like a real user would. It will send inputs to the application, observe the responses and analyze them for signs of security vulnerabilities. This dynamic approach allows the tool to identify vulnerabilities that static analysis tools might miss, such as runtime vulnerabilities and issues related to the application’s business logic.

5. Analyze and Prioritize Findings

Once the scanning process is complete, the next step is to analyze and prioritize the findings. The DAST tool will provide a report of the identified vulnerabilities, including their type, location and potential impact. This information should be used to prioritize the vulnerabilities based on their risk to the application and the business.

Analyzing and prioritizing the findings is not an easy task. It requires a deep understanding of the application, the business, and the threat landscape. You need to consider various factors, such as the potential impact of the vulnerability, the likelihood of exploitation, the sensitivity of the affected data, and the complexity of the remediation process. By considering these factors, you can prioritize the vulnerabilities and focus your efforts on those that pose the highest risk.

In addition, analyzing and prioritizing the findings should involve all relevant stakeholders. Developers, security teams, and business leaders should all participate in this process, as they each bring unique perspectives and insights that can help make better prioritization decisions.

6. Remediate and Retest

After analyzing and prioritizing the findings, the next step is to remediate the vulnerabilities and retest the application. Remediation involves modifying the application’s code or configuration to eliminate the identified vulnerabilities. Depending on the complexity of the vulnerabilities, this process can involve simple code changes or significant architectural modifications.

After remediation, it’s crucial to retest the application to ensure that the vulnerabilities have been effectively addressed. This involves running the DAST tool again and verifying that the previously identified vulnerabilities are no longer present. Additionally, retesting allows you to check for new vulnerabilities that might have been introduced during the remediation process.

Remediation and retesting is a continuous process. As new vulnerabilities are discovered and new features are developed, you will need to repeat this process to ensure the ongoing security of your application. This continuous effort is a critical component of the shift left with DAST strategy.

7. Continuous Monitoring and Updates

The final step in incorporating DAST into the CI/CD pipeline is continuous monitoring and updates. This involves regularly checking the effectiveness of the DAST tool, updating its configurations as the application evolves, and tuning it to reduce false positives.

Continuous monitoring and updates are crucial to maintaining the effectiveness of your shift left with DAST strategy. As the application evolves and the threat landscape changes, the DAST tool needs to be updated to remain effective.

Conclusion

In conclusion, incorporating DAST into the CI/CD pipeline is a powerful strategy to enhance the security of your software. By understanding the application structure, integrating DAST into the CI pipeline, configuring the DAST tool, scanning for vulnerabilities, analyzing and prioritizing findings, remediating and re-testing, and continuously monitoring and updating, you can unleash the power of shift left with DAST. This comprehensive approach will allow you to identify and address security vulnerabilities early in the development process, leading to more secure and reliable software.

July 18, 2023
The Security Pipeline

Over the last few years, the ability to secure our applications has grown, and deep integration into the DevOps toolchain has, too. There are more tools doing more security checks protecting more of the infrastructure and source than there have ever been. The key is putting them to use intelligently.

We now have the ability to secure the image an app is based upon, the images that are derived from that original—complete with supporting software. We can get feeds to tell us which bits of our included open source components are insecure and how to protect them; we can scan the source, the assembled application, the APIs and the network. We can put runtime protections in place in front of web apps and in front of APIs. We can even track the long-tail attacks like slow data extraction that are becoming more common as security tools master more obvious attacks.

That is a great set of security capabilities. And automation puts every bit of it within reach. Your job is to pick the bits you need to increase the security posture of your environment and get them worked into your specific toolchain. This is not all that difficult, but nothing is free, so you will need at least some implementation time and some staff time to work through results. After all, no matter how automated, current solutions do end with a list of changes that need to be made to increase security. Some tools will put a runtime fix in place immediately, but honestly, that is a patch—it only stays in place until you can fix the underlying issue.

Integrating all of the great security tooling with each other is another aspect that will require some time. Some vendors cover a massive amount of the security testing needed across markets and technologies. These companies show us that even if an organization would rather use best-of-breed, there is a lot of benefit in increasing integrations. For an easy example, consider this: If the software bill of materials (SBOM) generated during the build steps shows that a given framework is included in an application, then active testing via dynamic or interactive application security testing can include extra tests specific to that library.

Integrations will take effort, but once they’re in place they will enhance application security. There is no perfectly secure application, but the tooling is available to make a given environment less of a target because it is too much work to attack. And that is what you should be shooting for.

I’ve said before that making security part and parcel of your DevOps practices is mandatory at this point, but that was in reference to the great DevSecOps toolsets currently out there. I’m suggesting now that we include it all–from design to GitOps runtime drift management. Because we can, and the result is reduced risk to the organization.

And keep rocking it. Honestly, you’re maintaining something worth protecting–that alone means you are successful, even if you aren’t aware of every issue that crops up. Issues are why you’re there, and the systems keep running because you are.

June 21, 2023
Synopsys Preps Extensions to Polaris SaaS Platform

Synopsys plans to extend the capabilities of its Polaris Software Integrity Platform for securing application development environments by adding dynamic application security testing (DAST) tools along with the ability to scan code used to provision infrastructure.

As a software-as-a-service (SaaS) platform, the Polaris Software Integrity Platform was created by combining the static application security testing (SAST) tool Synopsys gained with the acquisition of Coverity in 2014 and the software composition analysis (SCA) tool it added to its portfolio by acquiring Black Duck Software in 2017.

In 2015, Synopsys acquired the Seeker tool for analyzing the code created using interactive application security testing (IAST) tools from Quotium. The company last year acquired WhiteHat Security from NTT to add a DAST tool.

Patrick Carey, senior director for marketing strategy for Synopsys, said that the company would add the capabilities of those latter two platforms to create a comprehensive set of best-in-class security tools that are easily accessible via a SaaS platform.

At a time when more organizations than ever are moving to secure software supply chains, Carey said it’s critical to provide developers with more visibility into vulnerabilities across the entire software development life cycle (SDLC). Some organizations are opting to achieve that goal by embedding tools within the SDLC themselves, but many organizations would likely prefer to invoke a SaaS platform that they don’t have to maintain, noted Carey.

He noted that a SaaS platform makes it simpler to point a collection of integrated tools at a code repository to surface those vulnerabilities.

As DevSecOps workflows continue to evolve and mature, more responsibility for application security is shifted left toward developers. The challenge is that many developers have limited cybersecurity expertise, so it’s critical that they have access to high-quality security tools.

In addition, a SaaS platform helps reduce the total cost of achieving that goal by providing multiple capabilities within a single integrated platform, said Carey.

Naturally, most of the focus today is on reducing the number of vulnerabilities that find their way into production environments as applications are being built. However, there are already large numbers of unaddressed vulnerabilities in applications that have already been deployed. Organizations will need to find ways to address that technical debt in addition to providing developers with tools that help prevent those code vulnerabilities in the first place.

As such, there is no one central place through which application security can be managed, noted Carey. Instead, application security needs to be addressed across every phase of the SDLC, he added.

It’s not clear how quickly organizations are adopting DevSecOps best practices, but as calls for increased liability for software development increase—as outlined, for example, in the U.S. National Cybersecurity Strategy— organizations should expect DevSecOps workflows to become a requirement. Otherwise, organizations will be severely penalized for vulnerabilities that find their way into code. In effect, there is now a race to embrace DevSecOps before any proposed liability legislation becomes the law of the land.

April 6, 2023
Addressing Software Supply Chain Security

It’s essential for organizations to learn more about the software supply chains they rely on and the steps needed to secure them. In just the past few years, we have seen a major uptick in malicious actors exploiting vulnerabilities in software supply chains to facilitate attacks on organizations. However, it’s important to remember that these attacks are not a new phenomenon. In fact, they’ve been around for decades. Therefore, the need to secure the software we rely on is not new, though the industry turning its attention to this problem is.

Software supply chain attacks are also far from simple. Given the fact that software supply chains are highly complex and made up of a number of constantly changing components, the avenues that malicious actors can take to pull off an attack are plentiful. For example, software artifacts are partially made up of components downloaded from open source software repositories. These platforms have become a favored attack avenue, given how frequently they are used by developers and the trust extended to them by development organizations. According to GitHub, anywhere from 85-97% of enterprise codebases come from open source repositories. Two of these repositories, npm and PyPI, have seen a nearly 300% spike in the number of attacks on their platforms in the past four years, impacting thousands of software supply chains globally.

One example of the kinds of software supply chain attacks that are now common is IconBurst, a major attack from last year where more than two dozen typosquatted packages were discovered on npm. As with other recent attacks, the IconBurst attackers used typosquatting – uploading malicious packages to repositories with names that closely resemble popular and legitimate packages on the same platform. Developers, in a rush to complete their work, are often tricked into downloading these typosquatted packages. In the case of the IconBurst campaign, for example, one of the malicious packages discovered was downloaded over 17,000 times!

Given the significant increase in the number of software supply chain attacks, organizations must make more of an effort to understand how these attacks work and then take steps to secure their software supply chains from compromise.

Say Goodbye to “Shift Left”

To begin with, development organizations need to reevaluate the mantra to “shift left.”

For years, industry leaders promoted the notion of “shifting left” as a call to marry application security with application development: Embedding secure development tools and practices into the continuous integration/continuous delivery (CI/CD) process. But times are changing and the industry is beginning to understand that while shifting left is necessary, it is not sufficient to secure software supply chains.

“Don’t shift left; shift everywhere!” said Tanya Janca, founder and CEO of WeHackPurple. Janca was speaking as a member of a recent Techstrong panel, “Software Supply Chain: It’s All About The Code” at the Predict 2023 virtual event. Janca pointed out the industry’s past fixation on “shift left” and the gaps in security that this caused since threats to the software supply chain not only happen during development but also throughout the entire software release process.

In fact, the notion of shifting left may do development organizations and developers a disservice: Leaving the work of securing applications entirely to them. “It’s unfair to expect developers to write perfect code,” said Jeff Williams, co-founder and CTO of Contrast Security, another member of the panel.

Software engineers are already under pressure to develop software quickly to meet development and project milestones. That makes it difficult for them to implement perfect security measures, like vetting every single line of third-party code they use while also watching out for social engineering attacks.

A New Approach to Secure the Software Supply Chain

For organizations looking to secure the software supply chains they rely on, they must choose the right tools. But much of the secure development and application security testing (AST) technology out there won’t cut it. For instance, tools such as dynamic or static application security testing (DAST/SAST) are critical components of the secure development life cycle (SDLC). However, they don’t provide holistic coverage of all of the supply chain threats out there, including software tampering and the risk posed by compromised open source and third-party libraries. On the other hand, tools such as software composition analysis (SCA) can help vet open source components but often fail to detect malicious modules or provide total security coverage of software supply chains. Knowing that your application depends on a malicious open source package after the fact is of little consolation when you release code at the speed of DevOps.

This is why modern tools that go beyond these capabilities should be considered. “It’s about giving developers the tools they need to be successful,” said GitLab’s CPO David DeSanto at the event. Experts in the space agree that change is needed but that developers and development teams aren’t set up for success as it stands.

According to Mat Matthews, an experienced practitioner in the DevOps space: “While developers are responsible for ensuring clean code, it takes a cross-functional team with a specific focus on security to reduce the attack surface against supply chain attacks.”

To accomplish that, organizations need to look to their security operations centers (SOCs) to take on a greater role in helping to secure software supply chains. Close collaboration between development and SOC teams is the surest way to provide end-to-end security for an organization’s software supply chains. And, supplied with the right tooling, SOCs and development teams working together will be better positioned to scan software packages; achieve greater visibility into development processes; detect deviations from a set baseline; and pursue possible supply chain compromises before they can cause real harm to software publishers and their customers.

As threats and attacks on software supply chains evolve, so must protections. A modern software supply chain security program should aim to protect the entire software development process, from the developer IDEs and their plugins to the open source components, CI/CD workflows and the release pipelines, while also being equipped to spot and pursue compromises at any point in the development life cycle. Only then will development teams be able to prevent harmful attacks like SUNBURST, IconBurst and countless others that have happened since.

March 15, 2023