devopsy.kinsta.cloud

Tag: vulnerability scanning

GitHub Widens the Door on Advanced Security Trials

Security tooling has a familiar adoption problem. The organizations that need it most — the ones scaling fast enough that their attack surface is outgrowing their process — are often the same ones that can’t justify a sales call and a signed contract just to see whether a product fits. They want to turn it on, run it against real repositories, and see what it actually finds before anyone talks pricing. GitHub just made that path available to a lot more of them.

The company raised the eligibility ceiling for self-serve GitHub Advanced Security (GHAS) trials, moving the cap from enterprises with up to 100 licenses to those with up to 300. Any GitHub Enterprise Cloud organization under that new threshold can start a 30-day trial directly from the “Billing and licensing” page in their enterprise settings, no sales conversation required. During the trial, an organization can add any number of committers and turn on both GitHub Secret Protection and GitHub Code Security across every organization it runs. If nothing is purchased by day 30, the trial simply expires.

That 100-to-300 jump sounds like a technicality, but it changes who gets to kick the tires without an approval chain. A 100-license cap puts self-serve trials mostly within reach of small teams and early-stage companies. Bump that to 300, and you’ve pulled in a much bigger band of the market: engineering organizations that are past the startup phase, running dozens of repositories, and dealing with exactly the kind of secret sprawl and dependency risk that GHAS is built to catch.

For anyone who hasn’t looked at GHAS lately, the trial covers the two pieces GitHub split out of the old bundled product last year: Code Security and Secret Protection. Code Security runs CodeQL scanning across a repository to flag vulnerable patterns and risky dependencies before they ship. Secret Protection scans for exposed credentials and API keys, and can block a pull request outright when it finds one, rather than just filing a report after the fact. Neither is new. What’s new is how many organizations can now turn both on, across every repository they own, without a purchase order in front of them first.

This isn’t GitHub’s first move to lower that friction this year. Back in May, the company let eligible admins launch a trial straight from a Secret Protection or Code Security risk assessment, instead of routing through a separate setup flow. In December, it opened trial eligibility to more Enterprise customers generally. It set a 180-day cooldown so organizations that tried GHAS once and passed could come back and try again later, rather than being locked out for good. Taken together, the pattern is consistent: GitHub keeps shortening the distance between “I’m curious about this” and “I’m actually running it against my code.”

Mitch Ashley, vice president and practice lead for CIO & Technology Buyers and Software Lifecycle Engineering at The Futurum Group, reads the change as more of a distribution play than a product one. “Widening self-serve trials is a distribution move that targets the real bottleneck in security tooling evaluations, which is usually procurement,” Ashley said. “Teams in that 100-to-300 band already carry the secret sprawl GHAS is built to find.” He also thinks the change resets what a trial actually needs to prove. “What a trial has to answer has changed. Scan-find-fix was built for code written at human speed,” he said. “Watch whether teams judge this on what it blocks at commit rather than what it reports on day 30.”

That second point is the sharper one. GHAS grew up around a scan-find-fix loop: code gets committed, a scanner catches what’s wrong, someone fixes it after the fact. That loop assumed code arriving at roughly the pace a person types it. With AI-assisted and agentic coding tools now generating a growing share of commits, a summary report on day 30 doesn’t say much about whether a tool keeps up when commits are landing faster than any one engineer can review. What Secret Protection blocks at the moment of commit — before an exposed key ever lands in a repository — is a more honest test of that than a scan tally at the end of the trial window.

There’s a practical caveat worth flagging for any team that’s been burned by “free trial” fine print before: GHAS trials are one-time-ish. An organization gets one shot, and if it lets that 30 days lapse without buying, the next attempt is 180 days out. That’s not a dealbreaker, but it does mean a team should treat the trial window as something to plan for, not something to click into on a slow afternoon. Point it at the repositories that actually matter — the ones with production traffic, the ones with the messiest dependency trees — instead of a clean demo repo that won’t tell you anything.

It’s also worth setting expectations before day one starts counting down. Thirty days sounds generous until a team accounts for the ramp-up: configuring both tools across dozens of repos, tuning out the false positives that show up in any first scan of a codebase nobody’s audited in a while, and getting enough eyes on the results to make an actual buy-or-pass decision. Teams that treat the first week as setup and the last as a decision meeting tend to get more out of a trial than ones that wait until day 25 to look at the dashboard.

None of this changes what GHAS is built to do. It still hunts down exposed secrets before they leak, and it still flags vulnerable and risky dependencies before they ship. What’s changed is who gets an easy, no-commitment way to find out whether it does that fast enough to matter — and, per Ashley, the bar for judging that just moved from the report to the moment of commit. For a mid-size engineering org that’s been putting off this evaluation because it didn’t want to sit through a sales pitch, that barrier just got a lot smaller.

September 11, 2026
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
Shift Left to the Developer’s Machine: Building Local Git Security Gates
A developer pushes one file. It contains an AWS access key left in a configuration block. Five minutes later, CI catches it. By then, the secret is in the remote repository, cached by mirrors and potentially forked. The developer rotates the key, scrubs the commit history and spends the rest of the afternoon on incident response. The real question isn’t how to clean up faster — it’s why the secret left the developer’s machine in the first place.

The Five-Minute Gap

Most engineering teams have invested in CI-based secret scanning. Tools such as GitHub Advanced Security, GitGuardian and TruffleHog’s CI integration catch leaked credentials in pull requests and pushed branches. This is good, but it’s also too late.

The GitGuardian 2026 State of Secrets Sprawl report found that 29 million secrets were detected on GitHub in 2025 alone — a 34% year-over-year increase and the largest single-year jump ever recorded. Worse, 64% of secrets leaked back in 2022 remain unrevoked even today. The gap between Git push and CI detection is typically 3 to 10 minutes. In that window, the secret hits the remote, enters reflog and becomes available to anyone with read access. Even if CI blocks the PR, the credential is already exposed in Git history.

Rotation mitigates the immediate risk. However, it doesn’t eliminate the exposure window and it doesn’t address the root cause: The secret should never have been committed.

Note: Without local security gates, secrets reach the remote before CI can intervene. With local gates, the commit is blocked before anything leaves the developer’s machine.

Two Gates, Two Purposes

Git provides two natural interception points on the developer’s machine: Pre-commit and pre-push hooks. Each serves a different security function.

The pre-commit gate focuses on secret detection. Before a commit is finalized, the hook scans staged files for API keys, tokens, passwords and other credential patterns. The critical detail: The scan should target the Git index (the staged snapshot), not the working tree. Scanning the working tree picks up unstaged experiments and editor temp files, producing false positives that train developers to ignore findings.

The pre-push gate handles broader security and quality concerns. Before code reaches the remote, the hook runs static analysis on changed files, checks dependency manifests against known vulnerability databases and optionally enforces test coverage thresholds. This gate is heavier, so it runs at push time rather than on every commit.

Note: The two-gate model separates fast secret detection (pre-commit) from deeper security and quality scanning (pre-push).

This separation matters. Secret detection needs to be fast and run on every commit — developers will bypass a hook that adds 30 seconds to their commit cycle. Vulnerability scanning and test execution are slower but acceptable at push time, when the developer is already context-switching.

What a Local Security Gate Should Do

A well-designed local security gate follows a few principles:
- Scan the Right Thing: Pre-commit scanning should materialize the Git index into a temporary snapshot and scan it, not the working tree. This ensures you’re checking exactly what will be committed, nothing more.
- Distinguish Verified From Unverified: Not all secret findings are equal. A confirmed live AWS key is a different severity than a string that matches a regex pattern. Tools such as TruffleHog can verify whether a detected credential is actually active. The gate should hard-block verified secrets while making unverified findings configurable — block or warn, the team decides.
- Require Accountability for Suppressions: Every codebase has false positives. The allowlist should require an owner, a reason and an expiration date for each suppression — no anonymous, permanent exceptions. When an allowlist entry expires, the gate should warn the developer and force a re-evaluation.
- Be Honest About Its Limits: Git hooks can be bypassed with –no-verify. Any local security gate is a guardrail, not a fence. It catches mistakes. It doesn’t prevent malice. The correct architecture pairs local gates with CI scanning to provide defense-in-depth.
Practical Implementation With Prehook

I built prehook (https://github.com/arunsanna/prehook) to implement this pattern as a single Go binary with no runtime dependencies beyond the scanner tools themselves. Here’s what the setup looks like:

prehook init       # generates .prehook.yaml with secure defaults
prehook install    # wires into .git/hooks/pre-commit and pre-push
prehook doctor     # validates all scanner binaries are present

The configuration is a single YAML file checked into the repository:

version: 1
pre_commit:
blocking: true
  gitleaks:
    enabled: true
    timeout: 2m
  trufflehog:
    enabled: true
    block_verified: true    # hard-block confirmed live secrets
    block_unknown: false    # warn on unverified findings

pre_push:
  semgrep:
    enabled: true
  osv:
    enabled: true           # skips if no dependency manifests changed
  trivy:
    severity: HIGH,CRITICAL
quality:
    test_command: go test ./…
    coverage:
      enabled: true
      threshold: 60         # minimum coverage percentage to push

The doctor command validates the local environment, checking that each enabled scanner is installed and optionally enforcing version pins. This is particularly useful for team onboarding — add prehook doctor to your setup documentation, and new developers know exactly what’s missing before they write their first commit.

Note: When the prehook catches a secret, the commit is blocked. The developer rotates the credential, removes it from the code and re-commits. Verified secrets are always blocked; unverified findings follow the team’s configured policy.

What This Pattern Doesn’t Solve

Local Git hooks are not a complete secrets management strategy. They are one layer in a defense-in-depth approach. Specifically:
- They can be bypassed. A developer running git commit –no-verify skips all hooks. This is by design in Git. CI scanning is the backstop that catches what local hooks miss, whether through bypass or misconfiguration.
- They don’t replace secrets management. The right answer is to never have secrets in code at all — use environment variables, vault systems or cloud IAM roles. Local hooks catch cases where that discipline breaks down, which happens inevitably.
- They require scanner installation. Unlike a SaaS CI integration, local hooks depend on each developer having the scanner binaries installed. This is a real adoption barrier. Tools such as prehook doctor reduce friction, but the dependency exists.
- The value proposition is not perfection. It’s catching the 90% of accidental leaks that happen because a developer was moving fast, testing locally or copying from a Stack Overflow answer including a placeholder key that wasn’t actually a placeholder.
Getting Started

If you want to implement local Git security gates on your team:
1. Start with secret detection only. Wire up Gitleaks or TruffleHog in a pre-commit hook. This is the highest-value, lowest-friction starting point.
2. Scan the index, not the working tree. Avoid false positives from unstaged changes.
3. Keep pre-commit fast. Under five seconds. Anything slower, and developers bypass it.
4. Add vulnerability scanning at push time. Semgrep, OSV-Scanner and Trivy are good options for the pre-push gate.
5. Pair with CI. Local hooks catch mistakes. CI enforces policy.
You can build this yourself with shell scripts, use a framework such as pre-commit or use a purpose-built tool such as prehook (https://github.com/arunsanna/prehook) that handles the index snapshot, scanner orchestration and allowlist management in a single binary.

The principle is what matters: Stop secrets before they ship. The tooling is a means to that end.

You can’t un-push a secret. However, you can stop it from being pushed in the first place.
June 12, 2026
Patch or Perish: The Brutal Truth About Vulnerability Management in 2025
Hackers aren’t breaking in; they’re merely walking through open doors.

In 2025, known vulnerabilities are the easiest way in. Thousands of companies are leaving them wide open.

This article dives into the truth about modern vulnerability management, why most teams are falling behind, what it’s costing them, and how to fix it before it’s too late.

The Vulnerability Landscape in 2025: Escalating Risks and Costs

As you read the news, it’s clear that vulnerability trends in 2025 are going up. Tens of thousands of new software flaws are being discovered every year. For example, over 40,000 CVEs (common vulnerabilities and exposures) were published in 2024, a 38% increase from 2023.

That’s more than 100 new bugs every day. You and your team are facing a never-ending flood of new vulnerabilities for attackers to exploit.

Breaches are not only more frequent but also very expensive. According to IBM’s 2023 Cost of a Data Breach report, the global average breach is around $4.45 million. Breaches caused by known but unpatched vulnerabilities (the kind you could have fixed months ago if you had time) still cost organizations around $4.17 million on average.

Even if it’s only one breach, these numbers show that forgetting to patch or monitor flaws can be a multi-million-dollar mistake for you and your company.

Cybersecurity risks in 2025 are high and getting higher. You now face thousands of new bugs a year and very high breach costs. And an exploit in your vendor’s software or an API you use can hurt you just as badly as an attack on your servers.

To stay safe, you need to be extra careful. Patch fast, monitor and secure any APIs, and vet your suppliers. Keeping on top of these trends is key to protecting yourself and your organization in 2025 and beyond.

Why Traditional Methods Fail

You may still be using periodic patch cycles or manual scans, but modern threats move much faster. New vulnerabilities are popping up all the time and are of high or critical severity. Old systems can’t keep up.

Experts say scan-based approaches are old school. You need continuous monitoring and automated fixes. Using modern vulnerability management tools, which rank and apply patches by risk, is the way to stay ahead.

Common Mistakes
- Delayed patching: You may delay updates to avoid downtime, but attackers won’t wait. Every extra day leaves a known hole open.
- Poor prioritization: You may treat all patches equally and spread your efforts too thin. In reality, most attacks hit long-known bugs. Using vulnerability management tools that rank issues by severity and business impact helps you focus on the riskiest flaws first.
- Insufficient testing: You might not test thoroughly because you’re afraid of breakage, but many teams pay the price. Always test patches in a safe environment and have rollback plans so you don’t miss critical fixes.
Next-Gen Vulnerability Management

Today’s vulnerability management tools use AI to help you focus on real risks. They move beyond static CVSS scores to use machine learning and real-world data.

For example, Cisco’s Kenna-based VM uses ML algorithms to predict exploit trends with about 94% accuracy, and Rapid7’s InsightVM applies an Active Risk AI model combining asset importance and live threat data.

These tools move you from reacting to every alert to hunting the small set of truly dangerous issues. What do ML-driven scores give you in practice?
- Tenable Predictive Prioritization: Narrow focus to the 3% of flaws that will be attacked, reducing your fix list by about 97%.
- Cisco Vulnerability Management: Leverages data science to forecast weaponization with 94% accuracy.
- Rapid7 InsightVM: uses an AI Active Risk score that combines live attacker behaviors and threat intel.
With these AI-powered scores, you’ll fix high-risk issues first and ignore the rest.

Vulnerability Management Tools and Services Comparison

You know that good vulnerability management tools are essential for protecting your company’s network. These include patch management systems, network and application vulnerability scanners, and risk-based prioritization platforms.

Now, we’ll compare these categories by how fast they respond to threats, how well they see your assets, how they integrate with your systems, and the quality of their reporting.

Patch Management (e.g, Microsoft Autopatch)

Patch management tools push out OS and software fixes to your devices. For example, Microsoft Autopatch automates Windows/Office updates at scale. These aren’t instant; they usually run on a schedule, but modern versions push critical patches quickly.

These tools give you compliance dashboards and reports so you can prove your systems are up-to-date.
- Real-time response: Patching is mostly scheduled, not instant. Critical fixes can be forced out quickly, but many patches still wait for testing. Automating this is key.
- Asset visibility: You need a complete inventory of devices and applications. Patch tools build or sync with asset lists so you see every endpoint and software version that needs updating.
- Integration: Patch solutions plug into your environment. They also work with DevOps by updating container images or integrating with CI/CD pipelines.
- Automation level: Very high. Most patch managers automatically download, test, and roll out patches. Thereby helps in reducing manual work and keeps you safer.
- Reporting and dashboards: Built-in dashboards show patch compliance, and you can generate audit reports for PCI or HIPAA. You can also keep track of how long it takes to remediate known CVEs across the network.
Vulnerability Scanning (e.g, Tenable, Rapid7)

Vulnerability scanning tools actively scan your network, cloud assets, and web apps for known flaws. You might run Tenable or Rapid7 to find missing patches, misconfigurations, and open services. These scanners often use AI in cybersecurity to go through millions of checks.

Scanners give you broad asset visibility. They discover servers, endpoints, containers, and cloud instances, and tag each asset with its vulnerabilities.
- Real-time response: Scanning isn’t truly real-time, but modern tools can run continuous or daily scans. They use automation and threat feeds, so when a new CVE appears, you can see it in your next scan soon.
- Asset visibility and tagging: These tools are great for discovery. They map your entire IT footprint and tag assets by type, OS, etc.
- Integration: Scanners plug into everything. Rapid7, Tenable, etc, all have connectors to XDR/SIEM, workflow tools, and orchestration platforms.
- Automation level: High. Scanning is usually scheduled and automated. The tools can auto-prioritize based on severity and sometimes even trigger remedial actions. Given the rising threats, automation in scanning and alerting is key.
- Reporting and dashboards: Scanners provide rich dashboards for compliance and risk metrics. You can generate reports of open vulnerabilities by severity, asset, or compliance standard.
Threat-Aware Prioritization (e.g, Vulcan Cyber, Kenna Security)

These platforms take your scanned data and add real-world context to rank vulnerabilities by risk. For example, Vulcan Cyber or Cisco’s Kenna will ingest vulnerabilities from scanners and layer on threat intelligence and asset criticality. So you see immediately which issues to fix. These tools give you a to-do list for remediation.
- Real-time response: By updating their risk scores with live threat feeds, they flag vulnerabilities as soon as they’re being exploited. If a new exploit hits a popular vulnerability, the system will alert you to patch ASAP.
- Asset visibility and tagging: They correlate vulnerabilities with your business context. For instance, you can tag critical assets, and the tool will show how many high-risk vulnerabilities are on those assets.
- Integration: These platforms sit on top of scanners and ticketing systems. They consume data from Rapid7/Tenable and threat intel feeds and can push tasks back to your patch manager.
- Automation level: They automate risk scoring and often auto-create remediation tasks. Many use machine learning to estimate exploit likelihood. This reduces manual analysis so your security team can act fast.
- Reporting and dashboards: You get risk-focused dashboards. They show a chart like “Top 10 most critical vulnerabilities.” You can see how you’re closing the gap on the biggest threats.
Best Practices for 2025

Threats are everywhere, and thousands of flaws appear every year. You have to be proactive. Follow these and use the right tools to future-proof your vulnerability management.
1. Scan and inspect your IT environment regularly. Focus on high-risk assets and follow the rules.
2. Prioritize by risk, not severity. Few flaws are being actively exploited.
3. Patching: Schedule and deploy patches.Don’t delay! Automation and staging testing before patch rollouts.
4. Confirm the vulnerability is closed after patching or configuration changes. Check fixes using follow-up scans or audits. Some tools reapply fixes if a scan finds the issue.
5. Continuous Monitoring: Fixing isn’t enough. 24/7 scans, intrusion warnings, and log analysis. Keep an eye on your attack surface to prevent gaps. Advanced tools can detect real-time threats using AI/ML and threat feeds.
Conclusion

Vulnerability management in 2025 is a survival strategy, not a best practice. Patching delays will hurt as threats get faster and more aggressive. Businesses must automate, be proactive, and treat unpatched systems as time bombs to be safe.
November 26, 2025
What Makes Vulnerability Scanning Effective in Fast-Moving DevSecOps Pipelines Today?
Speed is the currency of modern development, but security often pays the price. As teams push code faster than ever, traditional security methods can’t keep up. That’s where vulnerability scanning, done right, becomes essential. Not just as a checkbox, but as a real enabler of secure, continuous delivery.

In this blog, we will discuss what actually makes scanning effective in today’s rapid-fire CI/CD pipelines and why most teams still get it wrong.

Why Traditional Scanning Methods Fall Short in CI/CD

Traditional vulnerability scanning was never built for DevSecOps. It’s reactive, slow and often disconnected from the pace of modern software delivery.

You run a scan after deployment, get a 20-page report, and by the time you fix anything, five more features have shipped. Sound familiar?

That lag isn’t just inconvenient, it’s dangerous. In today’s world, where software changes by the hour, this model creates blind spots that attackers can easily exploit in the system.

What Does “Effective” Scanning Actually Mean Now?

To be effective today, vulnerability scanning needs to do three things well:
1. Work in real-time: Not weekly, not after release scanning, it should happen with every commit, merge, or deploy.
1. Understand context: Knowing there’s a vulnerability isn’t enough. You need to know if it’s actually exploitable in your environment.
1. Minimize noise: Developers don’t need hundreds of low-priority alerts. They need clarity on what to fix and why it matters.
Effective scanning in DevSecOps is about quality, not just quantity.

How Modern Scanners Fit Into the DevOps Workflow

Today’s best vulnerability scanners are tightly integrated into your CI/CD pipeline. They come in automatically for build or deploy steps, identifying problems before they ever hit production.

Rather than dealing with security as an ultimate gate, these tools incorporate it into the stream like linting or testing.

Some even connect with pull requests or ticketing systems, allowing developers to address issues without leaving their flow. This approach transforms security into a frictionless, invisible part of the process. And with 68% of organizations reporting a cyberattack in the past year, having security integrated into every step of development is more critical than ever.

“Security that doesn’t block delivery is the only kind that scales,” as every DevOps engineer will tell you eventually.

Why Real-Time Feedback Matters More Than Ever

Imagine writing code and getting security feedback instantly while your mental model is still fresh. That’s the advantage of inline or near-instant scanning.

Teams using scanners that deliver results within minutes (or even seconds) tend to fix vulnerabilities 5x faster, simply because the feedback loop is tighter.

It’s not about more alerts. It’s about the right alerts, at the right time.

What Capabilities Should You Actually Look For?

Let’s say your team just adopted a microservices architecture. Suddenly, you’re juggling internal APIs, cloud-native services, and third-party plugins — all at once. Your scanner needs to handle that chaos. It should plug directly into your CI pipeline, prioritize real threats, and provide results your developers actually understand. Anything less is dead weight.

How Do You Know It’s Working?

Metrics matter. Here’s what high-performing teams track:
- Time-to-fix (TTF): How fast are vulnerabilities remediated after discovery?
- Fix rate: What percentage of detected issues are actually resolved?
- False positive rate: Are devs ignoring results because they’re mostly noise?
If your scanner doesn’t help improve these metrics, it’s not helping.

Why Visibility Across the Stack Matters

In DevSecOps environments, risk can appear in various ways: Third-party dependencies, misconfigured APIs, overlooked authentication flaws, or changes in infrastructure-as-code. So, a vulnerability scanner must see bugs/threats across the entire stack, not limited to surface-level threats. It enables security teams and developers to trace how components are interacting with each other during runtime.

Also, it goes into depth, can detect a misused component in one service, and trace how it might create weak points across the ecosystems and that’s what separates them from just scanning to scanning with purpose.

Final Thoughts

Developers today don’t have the luxury of waiting for security to catch up. In pipelines that move by the hour, your scanning strategy needs to move just as fast and with just as much clarity. Vulnerability scanning is still critical, but only when it evolves beyond static reports and into real-time, context-aware, developer-friendly tools.

And in DevSecOps, those who scan smart not just often win.
September 11, 2025
Checkmarx Brings Generative AI to SAST and IaC Security Tools

Under an early access program, Checkmarx today made available query builder and guided automation tools that take advantage of OpenAI’s generative artificial intelligence (AI) technologies to make it simpler for developers to resolve application security issues.

AI Guided Remediation surfaces actionable remediation recommendations for vulnerability issues such as misconfigurations directly from within integrated development environments (IDEs).

Meanwhile, AI Query Builder makes it possible to use natural language text to create a query for both the Checkmarx static application security testing (SAST) and the infrastructure-as-code (IaC) security tool that creates rules for scanning code. Those rules can be easily fine-tuned or modified and queries for other use cases can easily be added.

In addition to reducing the amount of time it takes to create a query by 65%, that approach also dramatically reduces the number of false positive alerts that arise based on rules created by a security administrator.

Checkmarx CEO Sandeep Johri said these additions to the Checkmarx One Application Security Platform are aimed at improving the application security experience for developers. Most developers don’t want to be inundated by alerts that lack any real context, nor do they want to be bothered with remediation details.

It’s not likely developers will be interested in how AI could help them write more secure code from the start, but the faster a reliable fix is surfaced, the sooner developers can return to writing code, noted Johri.

In the longer term, Checkmarx will add support for multiple large language models (LLMs) beyond those provided by OpenAI to provide other AI capabilities that are based on more domain security knowledge, said Johri.

However, despite these advances, vulnerability remediation will not become fully automated using AI any time soon, he added. Instead, it will become much simpler to identify code that has either inadvertently or deliberately introduced a vulnerability, said Johri.

In fact, generative AI tools such as GitHub Copilot can themselves introduce vulnerabilities into code. As a general-purpose AI platform, the recommendations surfaced are based on a mix of instances of clean and flawed code, Johri noted. There will also be instances where cybercriminals attempt to subvert an LLM that creates code by injecting snippets loaded with malware into the samples used to train a generative AI model.

On the plus side, however, generative AI tools should narrow the divide that currently exists between application developers and cybersecurity teams as more issues are discovered and remediated before applications are deployed in a production environment. The challenge has aways been surfacing application security issues at the time developers are writing code rather than sending them a list of vulnerabilities to address weeks (sometimes even months) after a developer has moved on to another project.

Naturally, there is a lot of trepidation when it comes to all things generative AI; one area of certainty is that the benefits far outweigh the risks—especially when it comes to developing secure-by-default applications.

May 31, 2023
Mobb Launches Community Edition of Automated Remediation Tool

Mobb today made available a free community edition of a namesake tool that creates fixes to open source vulnerabilities. The fixes are based on the results of code scanning by a static application security testing (SAST) tool.

Fresh from raising $5.4 million in seed funding, Mobb CEO Eitan Worcel said the company developed a tool that creates validated patches based on the scan results of third-party SAST tools from Checkmarx, GitHub and Snyk. Initially, the tool is aimed at Java vulnerabilities.

Worcel said that most vulnerabilities can be traced back to eight types of mistakes that developers routinely make. The company created a pattern for those common mistakes, along with patterns to fix them, called Mobb rules. That ability enables Mobb to accurately produce a code fix that both remediates the vulnerability and adheres to the correctness of the language to eliminate code defects. Mobb then makes available a patch to address those issues in a way that can be readily downloaded and applied by developers. Mobb does not automatically apply those fixes because most developers prefer to review them first, noted Worcel.

The Mobb approach eliminates the need for IT teams to sort through SAST scans themselves, which can result in the discovery of thousands of vulnerabilities that might theoretically need to be fixed. Each vulnerability, at minimum, is going to require 30 minutes to fix, so the Mobb platform provides a better return on investment and reduces patch backlogs, added Worcel.

For decades, application development teams have been attempting to find a way to remediate vulnerabilities as quickly as possible. With increased focus on adopting DevSecOps best practices to address those vulnerabilities, more organizations are now reviewing which types of vulnerabilities should have a higher remediation priority.

Historically, one of the reasons for the wide divide between application development teams and cybersecurity professionals is that many of the vulnerabilities being discovered don’t actually impact applications running in production environments. Development teams then find themselves wasting time investigating vulnerabilities and, when they do determine a vulnerability is an issue, spending time developing a patch. The Mobb tool addresses that later issue by automatically creating the necessary patch, said Worcel.

Many organizations just allocate junior developers to the task of remediating vulnerabilities, which Worcel noted frees up more experienced developers to focus on writing additional business logic.

There will, of course, be vulnerabilities that the Mobb tool will not be able to address simply because there may not be enough affected applications to warrant pre-building a patch. Even with the most robust set of rules, it is improbable that an automated tool can, with 100% certainty, safely fix every issue. However, given the number of routine vulnerabilities present in applications, such as SQL injections, there’s plenty of opportunity to improve developer productivity by relying on patches that have already been developed.

One way or another, the process by which patches are prioritized, developed and then applied has long been a source of DevOps frustration. Anything that streamlines that process will go a long way toward improving the overall state of application security at a time when cybercriminals are becoming more adept at exploiting vulnerabilities wherever they may be found.

April 17, 2023
New Relic Bolsters Observability Platform

New Relic has updated its observability platform to include the ability to better detect and track errors in addition to monitoring vulnerabilities.

At the same time, an instance of the New Relic observability platform that runs natively on the Microsoft Azure cloud platform is now also generally available.

Manav Khurana, general manager for observability product and chief growth office for New Relic, said the alliance will enable Microsoft Azure customers to consume New Relic as part of their existing Microsoft Azure services contract.

New Relic already provides an errors inbox to track issues, but is now adding a tool to track the impact an error might have by correlating data across traces and logs. The company has also integrated its platform with Slack to make it simpler for IT teams to generate alerts when vulnerabilities are introduced into codebases and manage errors more collaboratively.

Similarly, New Relic is also looking to foster greater collaboration between software engineering and cybersecurity teams. A New Relic Vulnerability Management tool with no additional configuration required captures security signals generated via the company’s Telemetry Data Platform in a way that can be analyzed using an interactive application security testing (IAST) tool that New Relic gained with its acquisition of K2 Cyber Security. Additional IAST capabilities available in preview include the ability to leverage a patented deterministic technique to identify and provide automated vulnerability validation that highlights a proof-of-exploit.

The overall goal is to provide more visibility and context for organizations that are implementing best DevSecOps practices, said Khurana.

It’s still relatively early days as far as the integration of observability platforms into DevOps workflows is concerned. A recent survey conducted by New Relic found most organizations don’t expect to have robust observability practices in place by 2025. While most organizations have tools to monitor predefined metrics today, there is a significant gap between observability platforms that enable IT teams to determine the root cause of an IT issue and monitoring platforms that generate an alert whenever a threshold is exceeded.

In fact, many organizations have too many monitoring tools that often surface conflicting or redundant alerts, noted Khurana.

One way or another, more codebases are being instrumented. As that process continues to evolve, the agents embedded in that code make it simpler to collect the logs and traces needed to advance observability. The challenge, as always, is that it takes time for the number of fully instrumented applications to exceed the number of legacy applications that are either partially instrumented or not instrumented at all.

As IT environments become more complex, the need for observability is becoming much more pressing at a time when most IT teams are more short-handed than ever, noted Khurana.

Regardless of approach, there’s no doubt that observability, with patience, will impact the management of IT for the better.

January 30, 2023
Rezilion Updates Open Source MI-X Tool to Better Secure App Development

Rezilion has updated its open source MI-X vulnerability discovery tool to include mitigation and remediation recommendations.

In addition, the tool can now produce machine-readable output in either a JSON or CSV format.

Finally, the company added Windows support for Heartbleed and SpookySSL vulnerabilities in Windows environments.

MI-X makes it possible to use a command line interface (CLI) tool to identify and establish the exploitability of more than 20 well-known common vulnerabilities and exposures (CVEs).

Yotam Perkal, director of vulnerability research for Rezilion, said Rezilion created the tool as part of its efforts to create a platform that enables organizations to better secure their software supply chains. The primary purpose of the platform is to prevent vulnerabilities from being introduced into applications in the first place by providing developers with the context required to understand the potential severity of a vulnerability, he added.

There’s no doubt that developers need tools that enable them to easily identify vulnerabilities while writing code. However, shifting responsibility for vulnerabilities entirely left toward developers is not a panacea for application security. DevOps teams need to embrace DevSecOps best practices to ensure that the build created by multiple developers is secure and that the runtime environment where applications run is also free of malware.

The challenge is that achieving that goal needs to go beyond adding additional tools to a DevOps workflow. The biggest challenge is narrowing the historic cultural divide between developers and cybersecurity teams tasked with discovering vulnerabilities. Most cybersecurity professionals don’t understand how applications are developed, so every instance of vulnerability found in an application looks the same to them—regardless of whether the actual code is externally accessible.

DevOps teams, meanwhile, are trying to strike a delicate balance between patching innumerable vulnerabilities and building and deploying additional applications. More than anything, those teams need to be able to prioritize their patching efforts based on the actual versus theoretical severity of a vulnerability, noted Perkal.

It may never be possible to address all the application security debt application environments have accrued over the years. However, as apps are built and application security issues are addressed more proactively, the state of cybersecurity should improve. The issue, of course, is that cybercriminals are now targeting software supply chains; inserting malware into a DevOps workflow creates a potential opportunity to compromise any number of downstream applications. Organizations are now racing against time to secure their software supply chains.

The good news is that no developer intentionally sets out to build an insecure application. It’s just that far too many of them have been conditioned to think of security as an obstacle they need to overcome rather than address. However, the more tools they are provided to remediate as many vulnerabilities as possible, the better off everyone concerned will be.

December 19, 2022
WhiteSource Tool Automatically Fixes Code Vulnerabilities

WhiteSource today announced that it has developed the first-ever tool that automatically remediates vulnerabilities discovered in custom code.

Rami Sass, WhiteSource CEO, said WhiteSource Cure surfaces recommendations for fixing security vulnerabilities in code that developers can then apply with a click of a button. WhiteSource has a long history of providing tools that discover vulnerabilities in open source software that it tracks via a database it manages, but Sass said customers are making it clear they need a way to automatically remediate those issues in a way that doesn’t adversely impact developer productivity.

The average developer spends, on average, half a day fixing a single vulnerability, so the impact security issues are having on the rate applications are being developed is significant, added Sass. WhiteSource Cure gives each developer the equivalent of their own personal security expert, noted Sass.

Developers can either apply the remediation suggested by WhiteSource Cure—that manifests itself as a pull request in a DevOps pipeline—or they can fine-tune it as they see fit, said Sass.

WhiteSource Cure arrived as friction and tensions between developers and cybersecurity teams rise in the wake of a series of high-profile attacks against software supply chains. As a result, organizations are instituting more thorough security reviews of application development projects. The concern is those reviews will dramatically reduce the rate at which applications are being delivered.

Of course, many organizations are looking to shift responsibility for application security further left toward developers to minimize the number of vulnerabilities that might need to be remediated either just before an application is deployed in an on-premises IT environment or, worse yet, after it is deployed. Trying to achieve that goal within the context of DevSecOps best practices, however, is challenging. Organizations first have to acquire vulnerability scanning tools that developers will actually use, and then provide developers with the training required to identify various classes of vulnerabilities.

The other big challenge is the time it takes to train developers to recognize vulnerabilities. WhiteSource Cure eliminates the need for developers to become security experts, said Sass. In addition to a commercial offering, WhiteSource is also making available a Community Edition of WhiteSource Cure for open source projects that will forever be available for free to developers working on those projects.

Sass said that rather than relying on machine learning algorithms and other forms of artificial intelligence (AI) to build WhiteSource Cure, the team that developed the tool found that more traditional approaches to software composition analysis (SCA) provided more reliable results.

It’s unclear whether the ability to automatically remediate known vulnerabilities in code will render much of the DevSecOps debate moot. However, it’s clear that the simplest path forward toward achieving DevSecOps is, as always, to automate as much of the remediation process as possible. The challenge will be waiting to see how much confidence developers and cybersecurity teams will have in the recommendations generated.

July 28, 2021