devopsy.kinsta.cloud

Tag: Static Application Security Testing

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
Endor Labs Adds AI SAST Tool to Discover Vulnerabilities in Code

Endor Labs has developed a static application security testing (SAST) tool that leverages agentic artificial intelligence (AI) to more accurately identify vulnerabilities and other issues in code created in more than 40 programming languages.

Amod Gupta, vice president of product and design for Endor Labs, said the AI SAST tool the company develops combines a multi-modal static analysis engine, multiple AI agents and large language models (LLMs) to create the equivalent of a security engineer that analyzes code as it is developed.

The AI agents were built using a proprietary code application programming interface (API) that builds a model of how the code works in a way that provides additional context about the organization, added Gupta.

That approach enables the AI SAST tool to filter false positives by analyzing syntax, dataflow, and intent to reduce the number of false positives that SAST tools have historically generated by 92% on average, the company claims.

SAST AI will also review code for architectural and business logic flaws, such as broken access control and insecure design, and classify findings against the OWASP Top 10 security vulnerabilities framework. The AI agents will then surface recommendations to fix code based on the context they have been able to establish.

Finally, DevSecOps teams can also use natural-language prompts to teach SAST AI about specific practices and policies.

The SAST AI tool is arriving at a time when developers are relying on AI coding tools to generate more code than ever. That challenge is that AI coding tools typically invoke a general-purpose LLM that was trained using examples of code pulled from across the web that were often deeply flawed. The end result is that many of these tools are generating vulnerabilities in code that, on average, require 15 to 30 minutes each to triage.

Unfortunately, many application developers lack the cybersecurity expertise required to identify many of the vulnerabilities being generated. It’s then left to DevSecOps engineers to discover and remediate the rest before code is added to a production environment. Despite their best efforts, however, there are a lot more application developers than there are DevSecOps engineers, so more vulnerabilities are inevitably going to find their way into production environments.

The only way to break that cycle is to rely on AI to discover and help remediate the vulnerabilities being generated by AI coding tools, said Gupta. The issue is that organizations can not rely on the same LLM that was used to create code to also analyze that code for vulnerabilities, he added.

It’s probable that application security in the age of AI will get worse before it eventually gets better. Existing tools for analyzing code are often ignored by developers simply because they generate too many false positive alerts. As AI is incorporated into SAST tools, however, the overall level of noise generated by these tools should decline. In the meantime, DevOps teams should exercise more care. After all, if more of the code being created by AI tools winds up creating more security issues, the whole point of being able to build software faster becomes self-defeating.

November 25, 2025
A Seven Point Checklist for Getting SAST Right

With so many physical products—from automobiles to airplanes and medical devices to industrial control systems—now being driven by software, product security has become a top-level concern for manufacturers. Software flaws can not only affect security by introducing vulnerabilities that can be exploited by attackers but also impact safety by compromising a product’s functional operation.

In addition, product security has significant financial implications. For example, fixing a vulnerability in development costs 10 times less than in testing and 100 times less than fixing it in production. This explains why static application security testing (SAST) has become a cornerstone of product security and the engine for implementing code analysis at the earliest stages of development, commonly known as shift left security.

Unlike other forms of application security testing (AST), SAST scans 100% of the code, including configuration files, not just the code that is executed at runtime. SAST can also provide additional benefits, such as quality and architectural testing. Software quality and security are inextricably linked since poorly written software typically is insecure software.

With the stakes so high, getting SAST right is the tipping point for any product security program. To evaluate SAST tools, consider the following checklist to make sure they align with your business requirements:

1. Deep Language Support: C/C++, Java, C#, etc.

Languages are often selected based on the programmatic requirements of the software producer, the needs of the consumer and the hardware associated with the product. For example, developing software for safety-critical applications like aerospace requires different capabilities than languages used to build web applications.

2. Compiler and Embedded OS Platform Compatibility

Compilers used for embedded software development implement unique flags for configuration, such as performance optimizations, code size, error checking and the diagnostic information emitted. Since embedded OS platforms typically include compiler and debugging tools plus the various OS files and configuration options, make sure the SAST tool can integrate with the development environment used.

3. Actionable Alerts

For the DevOps team to embrace security, embedding security in the software factory life cycle cannot slow down development velocity or hinder developers’ ability to meet software release timelines. False positives redirect developer attention away from writing software to investigating potential defects. Too many false positives result in developers losing faith in true positives and paying less attention to security alerts of real substance.

4. Built-In DevOps Integration

The software development life cycle employs an extensive toolset that provides automation to help developers get products to the production stage faster—not unlike a manufacturing plant or factory. Make sure the SAST tool supports and integrates with distinct tool categories including collaboration and management, source control and repositories, IDEs, compilers, orchestration and automation and business intelligence.

5. Flexible Deployment

Depending on the organization and industry, SAST may need to support a variety of deployment options, including on-premises, cloud, hybrid, etc. For example, air-gapped deployments are often required in security-sensitive environments where the data protection uncertainty associated with multitenant public clouds is unacceptable. Meanwhile, cloud-based SAST can provide benefits like scalability and elasticity and reduce infrastructure capital investments.

6. Developer-friendly UI

Shift left security is accomplished by integrating security warnings into the integrated development environment (IDE) used by engineers. A SAST tool that works within existing IDEs can reduce the number of errors presented to testers, which subsequently reduces the volume of kickbacks to engineering and leads to faster time-to-market.

7. Standards

Many organizations use—and some must comply with—standards for software coding best practices such as SEI CERT, MISRA, etc., which provide a framework for improving the safety, reliability and security of software systems. In addition, a company may need to satisfy functional safety standards such ISE 61508, as well as derivative industry specific standards including IEC 62304 (Medical), ISO 26262 (Automotive), DO-178C (Avionics) and IEC 62434 (Security). A SAST tool should provide integration with key standards that govern an organization’s products and, where appropriate, be certified for them.

Using these guidelines for evaluating SAST tools will help ensure that the product you select meets your organization’s business, technology, safety and security requirements.

March 24, 2023
Snyk Extends Tools Portfolio to Drive DevSecOps Adoption

During its online SnykCon 2021 conference this week, Snyk extended Snyk Code, a static application security testing (SAST) tool that already supports the Java, JavaScript and Python programming languages to include support for C#, Ruby, PHP and Go.

At the same time, Snyk Open Source, a platform for remediating open source vulnerabilities, has been extended to provide native integration with Atlassian BitBucket and AWS CodePipeline platforms for driving DevOps workflows. Snyk has also tightened integrations with platforms from DigitalOcean and HashiCorp.

Snyk also added support for the Elixir programming language and package managers Yarn 2 and Poetry alongside integration with a C++ scanning tool from FossilID, a provider of a software composition analysis (SCA) tool for open source code that Snyk acquired earlier this year.

The Snyk Container platform is now integrated with the open source Trivy container scanning tools and with Snyk’s vulnerability database in addition to adding support for container registries such as Quay, GitHub Container Registry, GitLab, Google Artifact Registry and Harbor.

The Snyk infrastructure-as-code platform now also makes it possible to detect configuration issues in Kubernetes manifests in Terraform code in a way that is compatible with cloud platforms from Amazon Web Services (AWS), Microsoft Azure and Google Cloud Platform (GCP).

Snyk also is adding support for version 3 of OpenAPI, which the company reports is three times faster than the previous version. That API is also the foundation for Snyk Apps that the company will continue to roll out.

Finally, Snyk launched both a new free developer security education program, dubbed Snyk Learn, through which developers can attain and measure their level of DevSecOps expertise and Snyk Impact, an effort to foster collaboration among developers involving a wide range of socio-economic issues.

Company president Guy Podjamy said as DevsecOps continues to evolve, the primary focus remains on developers and DevOps teams. However, as an issue, DevSecOps is also becoming more important at both the C-level within organizations as well as individual security operations teams. As such, and in the wake of recent high-profile security breaches, the sense of urgency surrounding DevSecOps is now a lot higher. The fundamental challenge organizations are trying to address is finding a way to improve overall application security without slowing down the pace at which applications are built, noted Podjamy.

Snyk itself revealed it has secured an additional $530 million round of funding to address those issues. The company has now raised a total of $775 million to date with a valuation of $8.5 billion. Snyk also revealed it has increased annual recurring revenue (ARR) by 154% year-over-year from a customer base that now spans more than 1,200 organizations, including Asurion, Google, Intuit, MongoDB, New Relic, Revolut and Salesforce. Snyk customers and users collectively have run more than 300 million tests in the last 12 months to fix more than 30 million vulnerabilities in a 90-day period of time, the company claims.

It may be a while before most organizations have embedded security tools within every DevOps workflow. However, given the resources being poured into DevSecOps, it may be more a question when DevSecOps will be finally achieved rather than if.

October 8, 2021
What is SAST? Overview + SAST Tools
Static Application Security Testing Overview

With the growing number of cybersecurity threats, you must ensure that your software is protected against potential vulnerabilities and threats. One of the most beneficial practices is to use static application security testing (SAST).

What You Need to Know
Static application security testing is a type of software test used for inspecting and analyzing code to identify security vulnerabilities. Software security tools — such as static code analyzers — scan your code as it’s being written to identify potential weaknesses, errors and bugs. These kinds of tools are invaluable to software developers, as they are able to detect the most prevalent and common software security vulnerabilities.
How It Works
In the simplest terms, static application security testing works by having a static code analyzer check your code for design and coding flaws that could make your software vulnerable to security vulnerabilities. During this inspection, the static code analyzer will identify security issues, including programming errors, unsensitized input processing and vulnerable constructs.
Problems That It Solves
In general, static application security testing has been designed to solve three main software development problems:
To learn more about static application security testing and how it can help ensure the security of your software, please visit: https://www.perforce.com/blog/kw/what-is-sast?utm_source=content-syndication-devops&utm_medium=content-syndication&utm_campaign=kwk-global-2021-wtl-demo&utm_content=what-is-sast
January 11, 2021
3 DevOps Security Best Practices Your Organization Can’t Afford To Ignore
CI/CD pipelines are at the core of daily operations for many businesses today. These processes, when set up correctly, help to keep the delivery process consistent by automating many manual tasks and providing visibility into how the software is being worked on.

DevOps is also the place in your technology stack where your infrastructure has access to many different resources, from development and production environment to analytics keys and code signing credentials. The more resources your pipelines have access to (secure secrets, proprietary code, databases, etc.), the more important it is to keep your CI/CD system secure.

In this article, we talk about the different parts of DevOps security for CI/CD pipelines and highlight a number of ways to improve on these aspects. We usually divide security practices into three parts that you can address with different kinds of solutions:
1. Secure pipeline configuration
2. Code and Git history analysis
3. Security policy enforcement
All three aspects are equally important. Let’s take a deeper look at these categories and ways to address them.

Secure Pipeline Configuration

It is possible to use your CI/CD pipeline configuration to make security issues less likely to happen.

First, safely store secrets that you use in your pipelines for connecting to databases and third-party services. Depending on the CI platform you use, you may have the option to use encrypted-at-rest environment variables, or to use the contexts feature. Contexts are used to provide access to environment variables across projects. Their use can also be restricted to specific security group members as defined by the organization’s administrator.

Another option is to use a third-party solution to dynamically fetch secrets from their secure storage for your jobs. To ensure that none of your credentials become exposed to those who shouldn’t see them, you should never check these into your repository in plain text, even if the repository is private.

Second, for sensitive files like code signing keys, I recommend adding an additional layer of isolation between your encrypted files and your repository for added security. Keep them encrypted in your repository and store the decryption key in the environment variables or contexts, only decrypting them inside your CI/CD jobs when they are needed. This makes it even more difficult to expose or leak these highly sensitive files.

Third, you never want to leave your CI/CD environment running without monitoring it. Therefore, make sure that the containers and VMs used for your pipelines are destroyed after jobs that require sensitive information finish running.

Fourth, pay extra attention to how your CI/CD system handles builds for pull requests that come from forks of your repository. If your build stages require secrets to work, forked pull requests might gain access to them through your pipelines.

By addressing these four aspects you can significantly reduce the risk of security incidents due to your CI/CD pipeline configuration. Next up, code and Git history analysis.

Code and Git History Analysis

We all love Git for its comprehensive history of changes, being able to look through the history of the project with a simple CLI command and see who has most recently changed a line of code, among other benefits. This also means that any sensitive information that makes it into the Git history can be accessible to attackers if a Git repository is exposed, even if the most recent state of the repository doesn’t contain the secrets anymore.

Trufflehog and GitLeaks are two tools that can help you identify secrets that have been committed to the codebase so that you can deactivate and replace them. These two tools will also scan your Git history for traces of secrets that your team might have added to the repository in the past.

Once your Git history is clear of secrets, you can proceed to the next level: making sure that your current revision doesn’t contain any vulnerable dependencies.

Static Application Security Testing (SAST) techniques can look through the application in your commit and analyze its dependencies. If any dependencies contain any issues or known security vulnerabilities, your commit will be marked as insecure and won’t be allowed to proceed to deployment.

Dynamic Application Security Testing (DAST) techniques go one step further and spin up a copy of your production environment inside your CI job in order to scan the resulting containers and executables. The dynamic aspect helps the system catch dependencies that are being loaded at launch time, for example, as those won’t be caught by SAST.

Security Policy Enforcement

Some security aspects can’t be statically checked based on known vulnerabilities, but rather are specific to your particular company, and therefore need to be codified as policies. These can take the form of automated or manual compliance checks.

Certain tasks such as reviewing the list of all accounts that have access to your repositories, or making sure your onboarding and offboarding processes are in sync, will be manual. We recommend that you set reminders to perform these regularly.

Some tasks actually can be automated quite easily. For example, third-party services can provide a convenient way to codify a set of rules that will be matched against in your CI pipeline, e.g., proving compliance with the regulations that govern your data. If there is a mismatch, the build will fail.

Some of the Important Parts Can’t Be Automated

Keeping your CI/CD pipelines secure is more important today than ever before as automating your CI/CD practices requires more access to development and production environments, analytics keys and code signing credentials than in the past. The hard thing about security is that if you only get one of the three categories right, you won’t be 33% secure. You will be 0% secure until you get all the bases covered.

With the approaches outlined above, you’ll be in a much more secure position than you would be without them. However, some of the aspects that matter the most for CI/CD security can’t be automated or detected with an automated policy. These aspects are shaped by the behavior and culture within your team.

A DevSecOps Mindset

Your team is your most valuable set of security researchers because they know your applications best and constantly work on them. Have you implemented a clear process for your teammates to report security issues if they find any, and do you dedicate time to fix the security flaws they find? Do you celebrate those who report issues openly? In many companies, the answer isn’t an immediate “yes” to these, and it should be.

How long does it take for someone on your team to report suspicious activity? Do they need to post in multiple Slack channels to get attention, or is there a streamlined process to get an issue like this looked into? How do you treat those who report false positives — do you blame them for wasting the team’s time, or do you hold a blameless post-mortem so that everyone on your team learns from the mistakes? All these questions can make or break your security-minded development culture.
June 11, 2020