DEV Community: Nikolay Kuziev

Why Fixed Container Image Versions Matter: Lessons from the Trivy Supply Chain Attack

Nikolay Kuziev — Thu, 07 May 2026 05:39:20 +0000

A CI/CD pipeline is only as trustworthy as the code and tools it pulls during execution.

That sounds obvious, but it is easy to forget.

Most supply chain conversations start with application dependencies: Maven artifacts, Gradle dependencies, npm packages, base images, operating system packages, and third-party libraries.

But CI/CD tools are dependencies too.

The image used by a pipeline job is a dependency. The scanner image used in a security stage is a dependency. The GitHub Action used to scan containers is a dependency. The script downloaded with curl | sh is a dependency. The latest tag is also a dependency, but one that can change without a pull request.

That is the part I want to focus on here.

The Trivy supply chain incident is a useful case study because Trivy is not a random tool. It is a widely used security scanner. Many teams run it in CI/CD specifically to improve supply chain security.

That is the uncomfortable lesson:

a security scanner can also become a supply chain dependency

This does not mean "do not use Trivy".

It does not mean "security scanners are bad".

It means we need to treat CI/CD tooling with the same discipline we expect from application dependencies.

The minimum practical step is simple:

do not use floating image tags for security-critical CI/CD tooling

Use fixed versions. For stronger integrity, use image digests. For GitHub Actions, use full commit SHAs.

What happened with Trivy

In March 2026, Aqua Security published an advisory for a Trivy ecosystem supply chain compromise.

According to the Aqua Security advisory, on March 19, 2026, a threat actor used compromised credentials to publish a malicious Trivy v0.69.4 release, force-push most aquasecurity/trivy-action version tags to credential-stealing malware, and replace aquasecurity/setup-trivy tags with malicious commits.

The same advisory says that on March 22, 2026, malicious Docker Hub images were published for Trivy v0.69.5 and v0.69.6.

Docker's write-up adds the image-consumer view. Docker reported that Docker Hub customers may have been affected if they pulled aquasec/trivy with tags 0.69.4, 0.69.5, 0.69.6, or latest during the affected window between March 19 and March 23, 2026. Docker also described the latest tag being re-pointed during the incident.

That is exactly why mutable tags matter.

If a pipeline used this:

image: aquasec/trivy:latest

then the pipeline was not really saying:

use the Trivy version I reviewed

It was saying:

use whatever the latest tag points to at runtime

That difference is small in YAML and huge in security.

The problem is not only latest

The obvious bad example is latest.

But the deeper problem is mutability.

Docker's own build best practices explain that image tags are mutable: a publisher can update a tag so it points to a different image later. Docker also notes the downside for consumers: the same build can use different image content over time, and the exact version used becomes harder to audit.

So this is risky:

image: aquasec/trivy:latest

But this is not perfect either:

image: aquasec/trivy:0.69.3

It is better because the intended version is visible. It narrows the update surface. It makes the pipeline more readable.

But it is still a tag.

A tag can move.

The stronger form is:

image: aquasec/trivy:0.69.3@sha256:<pinned-image-digest>

The tag keeps the file human-readable. The digest pins the image content.

That is the practical difference:

tag:
  human-readable pointer that can change

digest:
  content identifier for a specific image

For security-sensitive CI/CD jobs, that difference matters.

The task: controlled updates instead of silent updates

The task is not "never update images".

That would create a different security problem.

The task is:

use controlled updates instead of silent updates

I want CI/CD tools to change through reviewable pull requests, not by silently pulling a changed tag during a pipeline run.

That applies to:

CI job images;
scanner images;
Dockerfile base images;
GitHub Actions;
Kubernetes workload images;
sidecar containers;
init containers;
build containers;
release tooling.

The goal is to make toolchain changes visible.

If Trivy changes from one version to another, I want that change to appear in Git history. If a digest changes, I want a pull request. If a scanner is upgraded, I want the pipeline diff to show what changed.

Not because every update must be slow.

Because invisible updates are hard to audit during an incident.

Why CI/CD images are high-trust dependencies

A scanner image running in CI/CD is not just another container.

It often has access to the repository checkout. It may read dependency files, Dockerfiles, Kubernetes manifests, lockfiles, SBOMs, source code, and build outputs.

Depending on the pipeline design, it may also run in an environment where secrets exist.

GitHub's security guidance warns that a compromised action inside a workflow can be significant because actions may access repository secrets and use the GITHUB_TOKEN. The same trust model applies to containerized CI tools.

If a CI job pulls a scanner image and runs it inside the pipeline, that image becomes part of the trusted execution path.

That is why I do not like treating CI tool versions casually.

A scanner is still code.

A scanner image is still a dependency.

A scanner action is still third-party execution inside a trusted pipeline.

The bad pattern

A common GitLab CI job might look like this:

trivy:image:
  image: aquasec/trivy:latest
  stage: security
  script:
    - trivy image "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

This is simple, but it has two problems.

First, the version is not controlled.

The pipeline may use different Trivy image content tomorrow without any change in the repository.

Second, incident response becomes harder.

If someone asks this:

Which exact Trivy image did this pipeline use last Tuesday?

the Git repository alone cannot answer it. The team may need registry logs, runner logs, caches, timestamps, and a lot of luck.

That is a weak audit trail.

A better pattern: fixed version

A better first step is to use a fixed version tag:

trivy:image:
  image: aquasec/trivy:0.69.3
  stage: security
  script:
    - trivy image "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

This is already better than latest.

It makes the intended version visible in Git. It reduces surprise. It makes updates explicit:

- image: aquasec/trivy:0.69.3
+ image: aquasec/trivy:0.70.0

For many teams, fixed tags are a practical starting point. They are readable and easy to adopt.

But for security-critical CI/CD tools, I would treat fixed tags as the minimum, not the end state.

The stronger pattern: version plus digest

The stronger pattern is to use both a readable version and a digest:

trivy:image:
  image: aquasec/trivy:0.69.3@sha256:<pinned-image-digest>
  stage: security
  script:
    - trivy image "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

This gives two benefits.

The tag keeps the file readable:

aquasec/trivy:0.69.3

The digest pins the content:

sha256:<pinned-image-digest>

Now the repository says:

use this exact image content

If the tag moves later, the digest still points to the committed image content.

Docker's documentation makes the same point for base images: pinning an image to a digest helps ensure the same image is used even if the publisher updates the tag. Docker also notes the tradeoff: pinned digests require an update workflow so teams do not miss security fixes.

That tradeoff is real.

Digest pinning gives control, but it also creates responsibility.

You need a process to update pins.

What the Trivy incident teaches here

The Aqua advisory explicitly says users were not affected if they used Trivy images referenced by digest.

That does not mean digest pinning solves every possible supply chain attack.

It means digest pinning changes the failure mode.

With a floating tag, your pipeline may silently start using newly pushed content.

With a pinned digest, your pipeline keeps using the exact content that was reviewed and committed.

That is a huge difference during incident response.

When something like this happens, teams need answers:

Did we pull the affected image?
Which pipelines used it?
Which version did we use?
Which digest did we use?
Which secrets existed in those jobs?
Which runners executed those jobs?
Do we need to rotate credentials?

Pinned versions and digests make those questions easier to answer.

Floating tags make them harder.

But pinned images get old

This is the strongest argument against pinning.

And it is not wrong.

If a team pins an image and forgets about it for two years, that is also bad.

Pinning is not supposed to mean:

never update this dependency

It means:

do not update this dependency invisibly

There is a big difference.

The workflow should look more like this:

pin image
scan image
run pipeline
create automated update pull requests
review digest changes
merge updates regularly
keep the audit trail

Docker's docs describe the same tradeoff: digest pinning improves reproducibility, but teams should have tooling that detects outdated pins and raises pull requests for controlled updates.

So the real rule is not:

pin and forget

The real rule is:

pin and update intentionally

CI/CD should not change without Git history

This is the main engineering point for me.

A pipeline should be reproducible enough that I can look at a commit and understand the tools that ran for that commit.

If the pipeline uses:

image: aquasec/trivy:latest

then the same commit can run with different Trivy contents on different days.

That is not reproducible.

If the pipeline uses:

image: aquasec/trivy:0.69.3@sha256:<pinned-image-digest>

then the tool is part of the commit state.

A change requires a diff. A diff can be reviewed. A review can be audited.

That is what I want from security tooling.

Not because every update needs a meeting.

Because CI/CD is part of the software supply chain, and supply chain changes should leave a trail.

Dockerfile base images have the same problem

This is not only about scanner images.

Base images have the same issue.

A Dockerfile like this is convenient:

FROM eclipse-temurin:17

But eclipse-temurin:17 is still a moving tag.

A more controlled version is:

FROM eclipse-temurin:17.0.11_9-jre

A stronger version is:

FROM eclipse-temurin:17.0.11_9-jre@sha256:<pinned-image-digest>

The same idea applies:

floating major tag:
  easy, but changes silently

specific version tag:
  better, but still mutable

version plus digest:
  stronger and more reproducible

For production images, I prefer the third form when the team has automation to update it.

Without update automation, teams often resist digests because they feel manual and annoying.

That is fair.

The solution is not to abandon digest pinning.

The solution is to automate digest updates through reviewable pull requests.

GitHub Actions need SHA pinning

Container images are pinned by digest.

GitHub Actions are pinned by full commit SHA.

This is the same principle in another format.

Weak:

- uses: aquasecurity/trivy-action@master

Better:

- uses: aquasecurity/trivy-action@0.35.0

Stronger:

- uses: aquasecurity/trivy-action@<full-commit-sha>

GitHub's own documentation says pinning an action to a full-length commit SHA is the only way to use an action as an immutable release. GitHub also provides repository and organization policies that can require full SHA pinning.

This matters because the Trivy incident affected both container images and GitHub Actions.

So the policy should cover both:

container image:
  pin by digest

GitHub Action:
  pin by full commit SHA

What I would standardize in CI/CD

If I were standardizing this across repositories, I would start with a small policy.

Not a huge platform rewrite.

Just a clear baseline:

no :latest in CI/CD jobs;
security scanner images must use fixed version tags;
high-trust CI/CD tooling should be pinned by digest;
GitHub Actions should be pinned by full commit SHA;
Dockerfile base images should use specific versions and preferably digests;
updates should happen through pull requests, not silent tag movement;
CI/CD should fail when new floating tags are introduced.

This is small enough to adopt.

But it changes the trust model.

The pipeline stops saying:

pull whatever this tag means today

and starts saying:

use this reviewed version of this tool

Example: GitLab CI with pinned Trivy image

A simple version:

variables:
  TRIVY_IMAGE: "aquasec/trivy:0.69.3"

trivy:image:
  image: "$TRIVY_IMAGE"
  stage: security
  script:
    - trivy image "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

A stronger version:

variables:
  TRIVY_IMAGE: "aquasec/trivy:0.69.3@sha256:<pinned-image-digest>"

trivy:image:
  image: "$TRIVY_IMAGE"
  stage: security
  script:
    - trivy image "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

I prefer keeping the image reference in a variable.

That makes updates easier to review:

 variables:
-  TRIVY_IMAGE: "aquasec/trivy:0.69.3@sha256:<old-digest>"
+  TRIVY_IMAGE: "aquasec/trivy:0.70.0@sha256:<new-digest>"

The diff clearly shows that the scanner changed.

That is exactly what I want.

Example: Docker run with digest

Some projects run Trivy through Docker directly:

docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy:latest \
  image my-service:local

I would avoid this in CI.

A better version:

docker run --rm \
  -v /var/run/docker.sock:/var/run/docker.sock \
  aquasec/trivy:0.69.3@sha256:<pinned-image-digest> \
  image my-service:local

The important part is not the exact command.

The important part is that the tool image is not resolved through a moving tag.

Example: Kubernetes workloads

The same problem exists in Kubernetes manifests.

Weak:

containers:
  - name: api
    image: registry.example.com/payment-api:latest

Better:

containers:
  - name: api
    image: registry.example.com/payment-api:1.14.2

Stronger:

containers:
  - name: api
    image: registry.example.com/payment-api:1.14.2@sha256:<pinned-image-digest>

For production Kubernetes workloads, I would also want policy enforcement:

reject :latest;
require image digests in production namespaces;
allow version tags in development namespaces;
require images from approved registries;
require signed images for critical workloads.

This is where Kyverno, OPA/Gatekeeper, admission controllers, and registry policies become useful.

But the first step is still cultural:

stop treating image tags as immutable versions

They are not.

How to detect the bad pattern

A simple first check can be basic.

For GitLab CI:

grep -R "image: .*:latest" .gitlab-ci.yml .gitlab-ci/ || true

For Dockerfiles:

grep -R "FROM .*:latest" Dockerfile* . || true

For Kubernetes manifests:

grep -R "image: .*:latest" k8s/ deploy/ helm/ || true

This is not a perfect policy engine.

It will miss some cases and produce false positives.

But it is a cheap starting point.

Later, a team can replace this with proper policy-as-code:

Semgrep rules for CI files and Dockerfiles;
OPA/Rego policies;
Kyverno policies;
GitLab or GitHub required checks;
admission control in Kubernetes;
registry allowlists and blocklists.

The practical rollout path is:

detect first
warn next
block later

Trying to block everything on day one usually creates too much friction.

What I would block immediately

There are a few patterns I would block immediately in production or security-sensitive CI/CD:

image: something:latest
docker run something:latest
FROM something:latest
uses: owner/action@master
uses: owner/action@main
curl ... | sh without version or checksum

These patterns make incident response harder.

They also make reproducibility weaker.

A pipeline should not depend on a moving target when it handles source code, secrets, cloud credentials, releases, or production artifacts.

What I would allow temporarily

There are cases where strict digest pinning may be too much at the beginning.

For example:

local experiments;
throwaway sandbox repositories;
early proof-of-concepts;
non-sensitive demo pipelines;
temporary development branches.

Even there, I would avoid latest when possible.

But security work is about risk and rollout.

The strongest policy should start where the risk is highest:

production deploy pipelines;
release pipelines;
cloud credential access;
container publishing jobs;
security scanning jobs;
jobs with secrets;
jobs that run on protected branches.

This makes adoption more realistic.

What pinning does not solve

Pinning is useful, but it is not magic.

It does not protect you if you pin a malicious digest.

It does not replace scanning.

It does not replace signature verification.

It does not replace least-privilege CI/CD tokens.

It does not replace secret rotation.

It does not replace egress controls.

It does not replace runner isolation.

It does not replace review of third-party tools.

It does not guarantee that a previously trusted image stays safe forever.

Pinning solves one specific problem:

it prevents silent movement from reviewed content to different content

That is valuable, but it is only one layer.

The bigger CI/CD hardening picture

The Trivy incident is not only a lesson about tags.

It is a lesson about how much trust we put into CI/CD.

A stronger pipeline should combine multiple controls:

pin images by digest;
pin GitHub Actions by full commit SHA;
use least-privilege tokens;
avoid long-lived credentials;
use OIDC for cloud access where possible;
restrict egress from runners;
separate trusted and untrusted workflows;
avoid running untrusted code with secrets;
rotate credentials after suspicious execution;
keep audit logs;
use short-lived runners for sensitive jobs;
scan artifacts before deployment.

Aqua's advisory also includes remediation themes such as rotating exposed secrets, auditing Trivy versions, auditing action references, and checking for exfiltration artifacts.

That is the broader lesson.

Pinning helps reduce unexpected dependency movement.

But CI/CD hardening also needs identity, isolation, permissions, monitoring, and incident response.

How this connects to my build tooling

In my Java secure build tooling articles, the main problem was security build drift.

The Gradle plugin article focuses on moving SonarQube, Dependency-Check, CycloneDX, and coverage conventions into the build system instead of duplicating scanner logic across CI/CD YAML.

The Maven extension article focuses on making normal Maven lifecycle commands security-aware so the build extension owns the security wiring and CI/CD stays smaller.

This article is about a different layer.

Even if the build system owns the security workflow, CI/CD still runs inside images.

Those images are part of the trust boundary.

For example, a GitLab CI job might use:

image: eclipse-temurin:17

That is readable and convenient, but it is still a tag.

For a stronger supply chain posture, the same principle applies:

image: eclipse-temurin:17@sha256:<pinned-image-digest>

The build system can reduce security configuration drift.

Pinned images reduce toolchain drift.

Both ideas point in the same direction:

security behavior should be explicit, versioned, and reviewable

Fixed versions vs fixed behavior

This is the part I think matters most.

Using fixed image versions is not only about security.

It is also about behavior.

If a scanner changes silently, findings can change silently.

If a base image changes silently, builds can change silently.

If a CI action changes silently, pipeline behavior can change silently.

That creates confusion:

Was this new finding caused by new code?
Was it caused by a new scanner version?
Was it caused by a changed vulnerability database?
Was it caused by a changed image?
Was it caused by a moved tag?

Security teams need signal.

Floating tags add noise.

Fixed versions and digests make changes easier to explain.

The workflow I prefer

For important CI/CD images, I prefer this workflow:

1. Choose a specific version.
2. Resolve its digest.
3. Commit image:tag@sha256:digest.
4. Scan the image.
5. Run the pipeline.
6. Automate update pull requests.
7. Review updates like dependency changes.
8. Merge intentionally.
9. Keep old pipeline history understandable.

This is not complicated.

It just treats CI tooling as real dependencies.

That is the mindset shift.

A practical team policy

A reasonable policy could look like this:

development:
  fixed version tags are recommended
  latest is discouraged

CI/CD with no secrets:
  fixed version tags are required
  digests are recommended

CI/CD with secrets:
  digests are required
  GitHub Actions must use full commit SHA
  no latest/main/master references

production:
  digests are required
  approved registries only
  automated update PRs required
  image scanning required

This is easier to roll out than one hard rule for everything.

It also matches risk.

The more privileged the environment, the less acceptable floating dependencies become.

A simple checklist

For every repository, I would ask:

Do CI jobs use :latest?
Do scanner jobs use fixed versions?
Do scanner jobs use digests?
Do Dockerfiles use floating base image tags?
Do GitHub Actions use tags instead of full SHAs?
Are image updates visible in pull requests?
Do we know which image digest ran in a past pipeline?
Can we block unsafe image references?
Can we rotate credentials quickly if a CI tool is compromised?
Are CI tokens least-privilege?

If the answer to most of these is "no", the pipeline is probably too trusting.

Not broken.

But too trusting.

What I learned from the Trivy incident

The biggest lesson is not that one specific version was bad.

The bigger lesson is that CI/CD pipelines often trust moving references.

The Trivy incident made that visible because the compromised component was a security tool.

That makes the situation feel ironic, but the engineering lesson is broader:

security tools are still dependencies
dependencies need version control
version control needs review
review needs an audit trail

A mutable tag is not an audit trail.

A digest is much closer to one.

Closing

I do not see fixed image versions as a paranoid practice.

I see them as normal supply chain hygiene.

If a pipeline pulls latest, the tool can change without a commit.

If a pipeline uses a fixed version, the intended version is visible.

If a pipeline uses a digest, the actual content is pinned.

That is the progression:

latest:
  convenient but risky

fixed version:
  better and easier to adopt

version plus digest:
  stronger and more reproducible

The Trivy supply chain incident showed why this matters in a very practical way.

A tool used to improve security became part of the attack path.

That does not mean we should stop using security tools.

It means we should run them like any other high-trust dependency:

pinned
reviewed
updated intentionally
auditable
least-privileged

Security tooling should not silently change under our feet.

Especially when that tooling runs inside CI/CD.

References

Don't Let Secrets Become Commits: Bringing Gitleaks Into the Developer Workflow

Nikolay Kuziev — Thu, 07 May 2026 04:19:46 +0000

I do not like discovering secrets in CI/CD.

Not because CI/CD secret scanning is useless. It is useful. It is necessary. I still want it in every serious pipeline.

The problem is timing.

When a token, password, private key, or API credential is detected in CI/CD, the code has already left the developer machine. It may already exist in a branch, a merge request, remote Git history, build logs, pipeline artifacts, caches, forks, or someone else's local clone. At that point the task is no longer just "remove the line from the code". The task becomes rotation, cleanup, investigation, and explaining why a preventable mistake reached shared infrastructure.

That is the part I wanted to remove from the normal development loop.

For secrets, the best finding is the one that appears before the commit exists.

The problem I kept running into

Most teams already have security tools. They have SAST. They have dependency scanning. They have CI/CD jobs. They have repository rules. They may even have secret detection enabled at the platform level.

But the first feedback often still appears after a push.

That means the developer workflow looks like this:

write code
commit
push
wait for pipeline
pipeline fails
open logs
find secret warning
fix locally
push again
maybe rotate credential
maybe clean history

This is not a great experience for developers, and it is not a great control for security teams.

A developer made the mistake locally, but the warning appears remotely. The context switch is unnecessary. The delay is unnecessary. The risk is unnecessary.

The uncomfortable truth is that CI/CD is often used as the first security feedback loop, when it should be the shared verification layer.

Why CI-only secret scanning is too late

A dependency vulnerability and a leaked secret are not the same class of problem.

If a library has a CVE, I can usually upgrade it, add a temporary mitigation, or accept the risk while the team plans a fix.

If a real credential lands in Git, I have to assume exposure. Even if the branch is private. Even if the commit is reverted. Even if the file was visible for only a few minutes. Git history and pipeline systems are not designed around pretending a committed secret never existed.

This is why I treat secrets differently.

For secrets, I want the first line of defense here:

before commit -> before push -> before CI/CD -> before review

Not because local checks are perfect. They are not. A developer can forget to install hooks. A hook can be bypassed. A scanner can miss something.

But a local hook catches the boring, obvious, expensive mistakes before they become shared problems.

That is already a win.

The principle: security checks should run where the mistake happens

The developer writes the code locally. The developer stages the change locally. The developer creates the commit locally.

So a part of the security feedback should also happen locally.

This matters for two reasons.

First, the code does not need to leave the machine just to catch obvious mistakes. A local scanner can inspect staged changes without sending source code to a remote service.

Second, the feedback is immediate. The developer does not need to wait for a pipeline, open a web UI, read a long job log, and then mentally reconnect the finding back to the line they just wrote.

The better loop looks like this:

write code
stage changes
try to commit
secret detected locally
fix it immediately
commit clean code

That is the kind of security control developers can actually live with.

The local layer: pre-commit plus Gitleaks

For this layer I use two pieces:

pre-commit -> manages Git hooks
Gitleaks   -> scans for secrets

pre-commit gives the repository a shared way to define hooks. Instead of asking every developer to manually create scripts inside .git/hooks, the project keeps one versioned configuration file:

.pre-commit-config.yaml

Gitleaks does the secret scanning. In this setup I care about one specific behavior: run the scan before Git creates the commit.

A minimal configuration looks like this:

repos:
  - repo: https://github.com/gitleaks/gitleaks
    rev: v8.24.2
    hooks:
      - id: gitleaks

Then the developer installs the hook once:

pip install pre-commit
pre-commit install

Before trusting it on an existing repository, I usually run the hook across the current tree:

pre-commit run --all-files

After that, the normal flow stays normal:

git add .
git commit -m "Implement payment validation"

The important part is what happens between git commit and the commit actually being created. The hook runs. Gitleaks scans the staged change. If it sees a likely secret, the commit stops locally.

No branch. No merge request. No pipeline artifact. No shared Git history.

Just a local warning at the point where the developer can fix it fastest.

I do not want this to become a README

The value is not the YAML snippet.

The value is the placement of the control.

A pre-commit hook is not a security program. It is not a replacement for CI/CD scanning, repository protection, secret management, review, or credential rotation. It is one small local safety net.

But it changes the tone of the workflow.

Instead of security saying:

You pushed a secret. Now go clean it up.

The tool says:

This looks like a secret.
Do not commit it.
Move it somewhere safe.
Try again.

That is a completely different developer experience.

Project-specific Gitleaks configuration

Default rules are useful, but real projects usually need a little tuning.

Test fixtures, documentation examples, generated samples, and fake tokens can produce false positives. I do not want developers fighting the tool every day, but I also do not want a giant allowlist that hides real problems.

A small .gitleaks.toml is usually enough:

title = "Project Gitleaks Configuration"

[extend]
useDefault = true

[[allowlists]]
description = "Allow fake examples in documentation and test fixtures"
paths = [
  '''docs/examples/.*''',
  '''src/test/resources/.*'''
]

[[allowlists]]
description = "Allow clearly fake placeholder values"
regexTarget = "line"
regexes = [
  '''not-a-real-secret''',
  '''example-token''',
  '''dummy-password'''
]

My rule for allowlists is simple: they should explain why the value is safe.

If the answer is "because it is annoying", that is not a good allowlist. If the answer is "because this directory contains fake examples used in tests", that is much better.

When Gitleaks reports something, the first question should be:

Is this a real credential?

Not:

How do I silence the scanner?

If it is real, the fix is to remove it from code, move it to environment variables or a secret manager, rotate it if needed, and check whether it reached remote history.

The allowlist is for false positives. It is not a trash bin for uncomfortable findings.

Where pre-commit ends and build tooling begins

I do not put every security check into pre-commit.

That is how good controls become hated controls.

A commit hook should be fast enough that developers do not look for ways around it. Secret scanning is a good fit because the impact is high and the check can be quick. Formatting, simple linting, YAML/JSON validation, and accidental large-file detection also fit well.

Heavier checks belong somewhere else.

The way I model it is:

pre-commit
  fast checks: secrets, formatting, simple file validation

pre-push
  medium checks: broader scans, policy validation, selected tests

build tooling layer
  full local project checks: SCA, SBOM, coverage, SonarQube metadata

CI/CD
  clean shared execution, gates, artifacts, enforcement

This is where my Java secure build tooling fits in.

For Gradle projects, I want a command like:

./gradlew clean securityAnalyze --no-daemon

For Maven projects, I want the normal lifecycle to carry the security workflow:

mvn verify

That build layer can run Dependency-Check, generate a CycloneDX SBOM, prepare coverage, and configure SonarQube metadata. It is heavier than a pre-commit hook, but it is still local-friendly and CI/CD-ready.

The key is that each layer has a job.

Gitleaks + pre-commit
  catches secrets before commit

Gradle/Maven build tooling
  runs repeatable AppSec checks locally and in CI/CD

CI/CD
  verifies the same workflow in a clean shared environment

This keeps security close to the developer without turning every commit into a full compliance audit.

CI/CD still stays in the design

Local hooks are not enough.

Someone can skip hook installation. A machine can be misconfigured. Automation can push code. A developer can bypass a hook intentionally. That is why I still run Gitleaks in CI/CD.

The design principle is not "local instead of CI".

The principle is:

local for fast feedback
CI/CD for enforcement

A simple CI job can use the same idea:

secret_scan:gitleaks:
  image:
    name: zricethezav/gitleaks:v8.24.2
    entrypoint: [""]
  stage: test
  script:
    - gitleaks git --redact --verbose

For direct local scans outside pre-commit, I prefer the current Gitleaks command style:

gitleaks git --redact --verbose
gitleaks dir --redact --verbose .

This gives security teams a shared safety net while still giving developers a faster local warning.

What developers get

Developers do not need another portal to check before every commit.

They need a clear signal in the workflow they already use.

A good local secret scanning setup gives them:

feedback before the mistake becomes Git history;
no need to upload code to catch obvious secrets;
fewer surprise pipeline failures;
a small, repeatable command set;
less back-and-forth with security for simple mistakes.

The best part is that the fix usually happens while the developer still remembers what they changed.

That matters more than people admit.

What the security team gets

Security teams get fewer noisy incidents and a better place to enforce basic hygiene.

Instead of treating every obvious secret as a pipeline incident, the team can push the simple feedback left and reserve CI/CD for shared verification.

They also get a cleaner story for Secure SDLC:

before commit: local secret scanning
before push: optional broader hooks
build: SCA, SBOM, coverage, SonarQube metadata
CI/CD: artifacts, gates, audit trail

That is much easier to explain, maintain, and improve than a pile of disconnected scanner jobs.

The part that matters

This is not really about Gitleaks.

Gitleaks is the tool I use under the hood. The more important idea is that security checks should be placed where they reduce cost the most.

For secrets, that place is before the commit.

For dependency analysis and SBOM generation, that place is usually the build tooling layer, with the same behavior available locally and in CI/CD.

For enforcement, that place is CI/CD.

When those layers work together, security stops feeling like an external inspection step and starts feeling like normal engineering feedback.

That is the workflow I want: fast locally, reproducible in CI/CD, and boring in the best possible way.

Making Maven Builds Security-Aware: AppSec Checks Without CI/CD Drift

Nikolay Kuziev — Thu, 07 May 2026 04:13:38 +0000

The problem was never that Maven projects could not run security tools.

They could.

A pipeline can run tests, Dependency-Check, CycloneDX, and SonarQube with a few commands. A pom.xml can hold plugin blocks. A team can copy a working configuration from one service to another and call it a standard.

For a while, that works.

Then the small differences start showing up.

One service has JaCoCo but does not pass the XML report to SonarQube. Another produces Dependency-Check output only as HTML. One multi-module project generates an SBOM from the root aggregator and misses the shape of the real runtime application. Another pipeline forgets merge request metadata, so SonarQube analysis is technically successful but practically incomplete.

That is security build drift.

It looks like automation. It behaves like inconsistency.

I built secure-maven-extension to solve that problem for Maven projects.

Not by replacing the scanners.

By making the Maven lifecycle carry the security workflow.

The problem I wanted to remove

A typical Maven CI/CD setup starts like this:

script:
  - ./mvnw test
  - ./mvnw org.owasp:dependency-check-maven:check
  - ./mvnw org.cyclonedx:cyclonedx-maven-plugin:makeBom
  - ./mvnw sonar:sonar

For one repository, this is fine.

Across many services, it becomes a maintenance pattern nobody really owns.

Some configuration lives in CI/CD. Some lives in pom.xml. Some lives in copied documentation. Some depends on environment variables that are not obvious to local developers. Every new service has to rediscover the same setup decisions.

The result is not only duplicated YAML.

The result is lower confidence.

If local runs do not match CI/CD, developers push just to test the security workflow. If reports are produced in different places, security teams waste time normalizing artifacts. If multi-module projects are wired differently, nobody knows whether the SBOM actually describes the deployable artifact.

At that point, the build is not security-aware. The pipeline is just calling scanners around it.

Why the usual approach is inconvenient

The usual approach puts too much responsibility into pipeline scripts.

CI/CD should be the shared execution layer. It should run clean builds, publish artifacts, enforce gates, and provide auditability.

But when CI/CD also owns all scanner configuration, every repository becomes a custom integration point.

That makes local development awkward.

A developer can run:

mvn verify

but the pipeline may run a different set of goals, with different properties, report formats, and SonarQube metadata. So the developer cannot fully trust the local result.

This is the gap I wanted to close.

The Maven command should stay familiar, but the lifecycle should carry the same AppSec behavior locally and in CI/CD.

The design principle

The core rule was this:

keep the Maven user experience native,
but inject repeatable security behavior into the lifecycle.

Developers should not need a separate security script for every service. CI/CD should not need to reimplement scanner conventions. Security teams should not need to explain report paths and plugin settings repository by repository.

The build should know how to do the boring parts.

That is why this project is a Maven core extension rather than just another command in a pipeline.

Why a Maven core extension

A normal Maven plugin would still require explicit plugin configuration across projects. That can work, but it does not fully remove copy-paste.

A core extension gives an earlier and more powerful integration point.

The extension is loaded from:

.mvn/extensions.xml

Example:

<extensions>
  <extension>
    <groupId>io.github.niki1337.securebuild</groupId>
    <artifactId>secure-maven-extension</artifactId>
    <version>0.1.0</version>
  </extension>
</extensions>

Internally, the extension works during Maven's afterProjectsRead stage.

That timing matters.

At that point, Maven has read the root pom.xml and module POMs. Packaging is known. Modules are visible. Existing plugins and properties can be inspected. But the lifecycle has not started yet.

That is the useful moment to inject conventions.

The extension can decide how to configure coverage, Dependency-Check, CycloneDX, and SonarQube before phases like initialize, package, and verify execute.

What runs under the hood

The extension connects the tools teams already know:

jacoco-maven-plugin for coverage;
sonar-maven-plugin for SonarQube analysis;
dependency-check-maven for dependency risk reports;
cyclonedx-maven-plugin for SBOM generation.

The developer still uses Maven:

mvn package
mvn verify
mvn sonar:sonar

The difference is that these commands become security-aware.

For example:

mvn package

can build the application and generate a CycloneDX SBOM.

mvn verify

can run tests, generate JaCoCo coverage, and execute Dependency-Check.

mvn verify sonar:sonar

can send SonarQube analysis with branch, merge request, binary, and coverage metadata already prepared.

That is the whole point: the workflow feels like Maven, not like a pile of scanner commands glued around Maven.

Configuration without forcing one style

Real environments are messy.

Local developers may use -D... properties. CI/CD usually provides environment variables. Some stable project defaults belong in pom.xml.

The extension supports all of those sources:

environment variables;
Maven user properties;
project properties from pom.xml;
system properties.

A project can define stable defaults:

<properties>
  <secure.serviceName>payment-api</secure.serviceName>
  <sonar.projectKey>payment-api</sonar.projectKey>
  <sonar.projectName>Payment API</sonar.projectName>
</properties>

CI/CD can provide secrets and environment-specific values:

export SERVICE_NAME="payment-api"
export SONAR_HOST_URL="https://sonarqube.example.com"
export SONAR_PROJECT_KEY="payment-api"
export SONAR_TOKEN="token-value"
export DT_API_URL="https://dependency-track.example.com"

A local developer can override when needed:

mvn verify \
  -Dsecure.serviceName=payment-api \
  -Dsonar.projectKey=payment-api

The goal is not to force one configuration style. The goal is to make the resolved behavior consistent.

Coverage should not require repeated wiring

Coverage is one of those details that quietly breaks AppSec workflows.

SonarQube can run without coverage, but the result is weaker. JaCoCo can generate a report, but if XML output is missing or the path is not passed to SonarQube, the analysis is incomplete.

The extension injects JaCoCo for Java jar and war projects when JaCoCo is not already configured.

It wires the lifecycle like this:

initialize -> jacoco:prepare-agent
verify     -> jacoco:report

The XML report is generated at:

target/site/jacoco/jacoco.xml

Then the extension passes that path into:

sonar.coverage.jacoco.xmlReportPaths

This is not exciting work. That is exactly why it should be automated.

Repeated boilerplate is where drift hides.

SonarQube needs more than a token

A common mistake is treating SonarQube setup as three variables: URL, project key, token.

For Java services, useful analysis also depends on source paths, test paths, compiled binaries, coverage XML, branch metadata, and merge request metadata.

The extension prepares properties such as:

sonar.sources
sonar.tests
sonar.java.binaries
sonar.java.test.binaries
sonar.coverage.jacoco.xmlReportPaths
sonar.exclusions
sonar.test.exclusions
sonar.cpd.exclusions
sonar.coverage.exclusions

In GitLab merge request pipelines, it can map CI variables into pull request analysis:

CI_MERGE_REQUEST_IID                  -> sonar.pullrequest.key
CI_MERGE_REQUEST_SOURCE_BRANCH_NAME   -> sonar.pullrequest.branch
CI_MERGE_REQUEST_TARGET_BRANCH_NAME   -> sonar.pullrequest.base

For normal branch pipelines, it sets branch analysis metadata.

This is the kind of logic that becomes fragile when copied into every pipeline file. Inside a core extension, the behavior is versioned and reusable.

Dependency-Check should produce one predictable shape

Dependency-Check is most useful when the output is predictable.

The extension injects Dependency-Check into the lifecycle:

single-module: verify -> dependency-check:check
multi-module:  verify -> dependency-check:aggregate

It standardizes report formats:

HTML
JSON
SARIF
XML

and writes reports to:

target/reports/dependency-check

By default, it disables network-dependent analyzers such as RetireJS, Node audit, Node package analyzer, OSS Index, and hosted suppressions. In restricted CI/CD environments, depending on external services can make builds slow, flaky, or inconsistent.

When an internal mirror exists, the extension can use it through:

DT_API_URL=https://dependency-track.example.com mvn verify

The default adoption path is visibility first. The build can generate reports without immediately failing by CVSS score. After the team understands the findings and noise level, policy gates can become stricter.

That is how I prefer to roll out AppSec checks: start with reliable data, then enforce deliberately.

SBOM generation should describe the real artifact

An SBOM is not useful just because it exists.

It should describe the thing the team actually ships.

For a single-module Maven application, the extension can run CycloneDX during package:

package -> cyclonedx:makeBom

Reports are written to:

target/reports/cyclonedx

The SBOM focuses on compile and runtime dependencies and avoids test, provided, and system scopes.

Multi-module builds need more care.

The root project is often only an aggregator. Generating an SBOM there can be less meaningful than generating it from the deployable application module. For Spring Boot projects, the extension looks for:

org.springframework.boot:spring-boot-maven-plugin

If it finds a deployable Spring Boot module, it injects CycloneDX there. If not, it falls back to aggregate SBOM generation on the root:

package -> cyclonedx:makeAggregateBom

This keeps SBOM generation tied to the application shape instead of blindly producing a file wherever Maven happens to start.

Multi-module Maven projects need first-class handling

Multi-module Maven builds are where simple CI snippets start to fall apart.

A root project may have pom packaging. Modules may be jar or war. Some modules are deployable, some are libraries, some are test fixtures. Coverage should be generated per Java module. Dependency-Check may need aggregate behavior. SonarQube needs paths that reflect the whole project.

The extension treats a build as multi-module when Maven sees more than one project and simple mode is not forced. It includes Java modules with jar and war packaging and supports filters like:

<properties>
  <secure.includedModules>api,service</secure.includedModules>
  <secure.excludedModules>test-fixtures</secure.excludedModules>
</properties>

In multi-module mode, it configures SonarQube on the root, injects JaCoCo into Java modules, adds module-level paths, runs aggregate Dependency-Check, and generates SBOM output from the most useful module when possible.

That is the difference between running a scanner and owning a build convention.

CI/CD becomes an execution layer

Once Maven owns the conventions, CI/CD can stay small.

A security job can be simple:

security:maven:
  image: eclipse-temurin:17
  stage: test
  script:
    - ./mvnw -B verify
  artifacts:
    when: always
    expire_in: 7 days
    paths:
      - target/reports/dependency-check/
      - target/reports/cyclonedx/
      - "**/target/reports/dependency-check/"
      - "**/target/reports/cyclonedx/"
      - "**/target/site/jacoco/"

SonarQube can run only when a token is available:

sonarqube:maven:
  image: eclipse-temurin:17
  stage: test
  script:
    - ./mvnw -B verify sonar:sonar
  rules:
    - if: '$SONAR_TOKEN'

The pipeline is now readable because the security wiring is no longer scattered through the YAML.

The build owns the behavior. CI/CD runs it.

Where pre-commit and Gitleaks fit

The Maven extension is not the earliest security layer.

For secrets, I want feedback before the commit exists. That is where pre-commit and Gitleaks fit. A local secret scanning hook can stop obvious leaks before code leaves the developer machine.

The Maven extension handles the next layer: build-time checks that understand Java, dependencies, coverage, SBOM generation, and SonarQube metadata.

The model is layered:

before commit
  pre-commit hooks, Gitleaks, fast file checks

local build
  mvn verify, coverage, Dependency-Check, CycloneDX SBOM

CI/CD
  same Maven lifecycle, artifacts, gates, enforcement

This is important because not every check belongs in the same place.

Secret scanning is fast and high-impact, so it belongs very early. Dependency analysis and SBOM generation are heavier and build-aware, so they belong in the build. Final enforcement belongs in CI/CD.

That separation keeps the workflow practical.

What developers get

Developers get to keep using Maven.

They do not need to memorize a custom AppSec script for every repository. They do not need to push a branch just to learn whether Dependency-Check or SonarQube wiring works. They can run familiar lifecycle commands and get security-aware behavior locally.

That makes findings easier to understand. The report appears in the same build context where the code was changed.

This matters because good security tooling is not only about detection. It is also about timing, clarity, and trust.

What the security team gets

The security team gets fewer custom integrations to chase.

Reports are generated in predictable formats and locations. SBOM scope becomes more consistent. Coverage is wired into SonarQube. Merge request metadata is handled in one reusable layer. Multi-module projects stop being a special case every time.

This also makes policy easier to evolve.

The team can start with visibility, collect reports, understand noise, and then introduce stricter gates when the data is reliable.

That is much better than turning on hard failures before anyone trusts the output.

The result

secure-maven-extension is not another security scanner.

It is a build tooling layer for Maven-based Java projects.

It moves repeated AppSec wiring out of CI/CD YAML and into the Maven lifecycle, where developers can run it locally and CI/CD can reproduce it cleanly.

The larger pattern is the same one I use across the whole workflow:

local hooks for fast mistakes
build tooling for repeatable project checks
CI/CD for shared verification and enforcement

When that pattern works, security stops being an external script attached to the project and becomes part of how the project is built.

That is the real goal.

Project links:

Stop Copy-Pasting Security YAML: A Gradle Build Layer for Java AppSec

Nikolay Kuziev — Thu, 07 May 2026 04:12:22 +0000

The hard part of Java AppSec is usually not finding another scanner.

Most teams already have the scanners.

They have SonarQube for code analysis. They have OWASP Dependency-Check for dependency risk. They have CycloneDX for SBOM generation. They have JaCoCo or Kover for coverage. They have GitLab CI, GitHub Actions, Jenkins, or something similar to run all of it.

And still, the workflow drifts.

One repository writes Dependency-Check reports to one path. Another produces only HTML. One pipeline sends merge request metadata to SonarQube correctly. Another accidentally runs branch analysis for everything. One service generates an SBOM from runtime dependencies. Another includes test dependencies and makes the report noisy. A multi-module project needs a special exception, so someone copies another YAML block and edits it until the pipeline is green.

None of this looks dramatic on day one.

After a few months, it becomes security build drift.

That is the problem I wanted to solve with secure-build-gradle-plugin.

Not by inventing a new scanner.

By moving security wiring into a reusable Gradle build layer.

The problem I ran into

The usual DevSecOps starting point is CI/CD YAML.

For a single Java service, this is fine:

script:
  - ./gradlew test
  - ./gradlew dependencyCheckAnalyze
  - ./gradlew cyclonedxBom
  - ./gradlew sonar

It is direct. It is visible. It works.

The problem starts when the same idea spreads across many repositories.

Every service becomes responsible for remembering how security tools should be configured. Every team copies a slightly different version. Every pipeline slowly becomes a custom integration.

The failure mode is not only technical. It affects trust.

Developers do not know which command reproduces the pipeline locally. Security teams do not know whether two reports were generated with the same assumptions. CI/CD becomes full of scanner plumbing instead of clear build steps.

At that point, the issue is not "we need more tools".

The issue is "we need one place for the conventions".

Why CI/CD-only security wiring is uncomfortable

CI/CD is good at clean execution. It gives a fresh environment, shared logs, artifacts, gates, and a common place for enforcement.

But CI/CD is not a great place to own all security behavior.

When the logic lives only in pipeline files, local development becomes second-class. Developers push to find out what the security workflow thinks. If a report path is wrong, the pipeline fails. If SonarQube metadata is incomplete, the analysis is misleading. If Dependency-Check output differs between services, the security team has to normalize the mess later.

This creates the worst kind of friction: nobody is arguing about risk yet. Everyone is arguing about tool wiring.

I wanted CI/CD to execute the security workflow, not define it from scratch in every repository.

That distinction matters.

The design principle

The rule I used for the Gradle plugin was simple:

security behavior should live close to the code,
and CI/CD should run the same behavior without reimplementing it.

That means developers should be able to run the same checks before opening a merge request:

./gradlew clean securityAnalyze --no-daemon

And CI/CD should be able to run the same task and collect predictable reports.

The result should not depend on whether the command was executed on a laptop or inside a pipeline, except for environment-specific details like tokens and branch metadata.

That is the point of the build tooling layer.

The build tooling layer

secure-build-gradle-plugin is a Gradle convention plugin.

A project applies the plugin once:

plugins {
  id "java"
  id "io.github.niki1337.securebuild.gradle-java" version "0.1.0"
}

Then the project keeps only project-specific values in one place:

securityConventions {
  serviceName = "payment-api"
  sonarProjectKey = "payment-api"
  allowLocalSonar = false
}

For a multi-module project, the root build can describe which modules matter:

plugins {
  id "io.github.niki1337.securebuild.gradle-java" version "0.1.0"
}

securityConventions {
  serviceName = "payments-platform"
  sonarProjectKey = "payments-platform"
  includedModules = ["api", "service"]
  excludedModules = ["test-fixtures"]
}

That changes the ownership model.

CI/CD still runs the checks. Security still owns policy. Developers still fix findings.

But the repeated scanner wiring lives in the build system, versioned as engineering code instead of copy-pasted as pipeline folklore.

What runs under the hood

The plugin connects existing tools:

SonarQube analysis;
OWASP Dependency-Check;
CycloneDX SBOM generation;
JaCoCo or Kover coverage;
Gradle single-module and multi-module behavior;
Git branch and GitLab merge request metadata.

The plugin is not trying to replace those tools. That would be the wrong abstraction.

The value is in making them behave consistently.

A developer gets one practical entry point:

./gradlew clean securityAnalyze --no-daemon

That task can run tests, produce coverage, generate SBOM output, and run dependency analysis. When a developer needs to inspect individual pieces, the underlying tasks are still there:

./gradlew cyclonedxDirectBom --no-daemon
./gradlew dependencyCheckAnalyze --no-daemon
./gradlew sonarHelp --no-daemon

For multi-module builds, aggregate analysis stays explicit:

./gradlew dependencyCheckAggregate --no-daemon

The point is not to hide the tools. The point is to make the normal path obvious.

Moving feedback before the merge request

One of the biggest wins is psychological.

If AppSec checks run only after a push, developers treat findings as pipeline problems. If they can run the same workflow locally, findings become engineering feedback.

That is a healthier model.

A developer can run:

./gradlew securityAnalyze --no-daemon

before opening a merge request. They can see dependency findings, SBOM output, coverage reports, and local scanner artifacts before the branch becomes a shared review object.

CI/CD still matters. I do not trust laptops as the final gate. But local execution reduces surprise, and reducing surprise is one of the best ways to make security tooling accepted.

SonarQube metadata belongs in conventions

SonarQube is easy to configure almost correctly.

That is the dangerous part.

The scanner may run, the job may pass, and the analysis may still be incomplete because Java binaries, libraries, coverage XML, branch names, or merge request metadata were not passed correctly.

That is why I do not want every repository hand-writing this logic.

The plugin resolves SonarQube configuration from environment variables, Gradle properties, or the securityConventions block:

export SONAR_HOST_URL="https://sonarqube.example.com"
export SONAR_PROJECT_KEY="payment-api"
export SONAR_TOKEN="token-value"

Then it prepares the Java analysis properties that teams usually forget at least once:

sonar.sources
sonar.tests
sonar.java.binaries
sonar.java.test.binaries
sonar.java.libraries
sonar.java.test.libraries
sonar.coverage.jacoco.xmlReportPaths
sonar.exclusions
sonar.test.exclusions
sonar.cpd.exclusions
sonar.coverage.exclusions

In GitLab merge request pipelines, it can map CI variables to SonarQube pull request properties:

CI_MERGE_REQUEST_IID                  -> sonar.pullrequest.key
CI_MERGE_REQUEST_SOURCE_BRANCH_NAME   -> sonar.pullrequest.branch
CI_MERGE_REQUEST_TARGET_BRANCH_NAME   -> sonar.pullrequest.base

For branch pipelines, it sets branch analysis metadata instead.

This is exactly the kind of boring detail that should be solved once and reused.

Dependency-Check reports should be boring

Dependency-Check is useful when reports are predictable.

I do not want one service producing JSON, another producing only HTML, and another hiding reports in a custom directory. That creates unnecessary work downstream.

The plugin standardizes formats:

HTML
JSON
SARIF
XML

and writes reports to:

build/reports/dependency-check

By default, it avoids depending on network-heavy analyzers that can make CI/CD slow or unstable in restricted environments, such as OSS Index, RetireJS, Node audit, Node package analysis, hosted suppressions, and CISA KEV analyzer.

If an internal mirror exists, the build can use it through configuration like:

DT_API_URL=https://dependency-track.example.com \
./gradlew dependencyCheckAnalyze --no-daemon

The default behavior is visibility first, not instant blocking. A build can generate useful reports without failing by CVSS score immediately. Once the team understands the noise and triage process, stricter gates can be introduced deliberately.

That is a practical AppSec adoption path.

SBOM output should describe the runtime artifact

SBOM generation is not valuable just because a file exists.

The SBOM has to describe something useful.

If one service includes test dependencies and another does not, comparison becomes messy. If a multi-module root project is only an aggregator, a root-level SBOM may say very little about the deployable application.

The plugin configures CycloneDX with runtime-oriented output in mind:

runtime dependencies included
test dependencies skipped
license text not embedded
BOM serial number disabled
metadata noise reduced

Typical output paths stay predictable:

build/reports/cyclonedx
build/reports/cyclonedx-direct

For Spring Boot style multi-module projects, the useful SBOM often comes from the deployable module, not the root. The plugin tries to make that the default path while still copying reports back to predictable root locations for CI/CD artifact collection.

This is the kind of detail that looks small until you have ten services and every one produces a different SBOM shape.

Coverage wiring should not be tribal knowledge

Coverage is another source of drift.

Some projects use JaCoCo. Some already use Kover. Some generate XML. Some do not. Some pass the report to SonarQube. Some forget.

The plugin supports a simple default:

securityConventions {
  coverageProvider = "auto"
}

In auto mode, it uses Kover when Kover is already present. Otherwise, it applies and configures JaCoCo.

For JaCoCo, it enables XML output and wires the standard path into SonarQube:

build/reports/jacoco/test/jacocoTestReport.xml

Again, not glamorous. Just useful.

A good build convention removes repeated decisions that are easy to get wrong.

Multi-module Gradle builds are where this pays off

Single-module scanner integration is easy to demo.

Multi-module builds are where the real problems appear.

A root project may not contain production code. Some modules are deployable. Some are libraries. Some are test fixtures. Some should be excluded from coverage or dependency analysis. SonarQube needs paths per module. Dependency-Check may need aggregate behavior. SBOM generation should describe the deployable artifact.

The plugin detects Java subprojects using java and java-library, supports module filters, configures coverage per Java module, collects XML paths, prepares root-level SonarQube analysis, and exposes a root-level security workflow.

A root command can still drive the work:

./gradlew clean securityAnalyze --no-daemon

That is the difference between a scanner integration and a build tooling layer.

CI/CD becomes smaller

Once the build owns the security wiring, CI/CD becomes easier to read.

A GitLab job can be this boring:

security:gradle:
  image: eclipse-temurin:17
  stage: test
  variables:
    GRADLE_USER_HOME: "$CI_PROJECT_DIR/.gradle"
  script:
    - ./gradlew clean securityAnalyze --no-daemon
  artifacts:
    when: always
    expire_in: 7 days
    paths:
      - build/reports/dependency-check/
      - build/reports/cyclonedx/
      - build/reports/cyclonedx-direct/
      - "**/build/reports/jacoco/"

SonarQube can stay separate and token-driven:

sonarqube:gradle:
  image: eclipse-temurin:17
  stage: test
  script:
    - ./gradlew sonar --no-daemon
  rules:
    - if: '$SONAR_TOKEN'

The important part is architectural:

CI/CD calls build tasks.
CI/CD does not reimplement the build conventions.

Where pre-commit and Gitleaks fit

I do not see the Gradle plugin as the first security layer.

For secrets, I want something earlier.

A pre-commit hook with Gitleaks can catch obvious secrets before a commit exists. That is the right place for that class of finding.

The Gradle plugin covers the next layer: build-time AppSec checks that are heavier than a commit hook but still useful before code is pushed or reviewed.

The layered model looks like this:

before commit
  Gitleaks + pre-commit

before review
  ./gradlew securityAnalyze

after push
  CI/CD runs the same build tasks and publishes artifacts

This keeps pre-commit fast, keeps Gradle responsible for build-aware checks, and keeps CI/CD responsible for enforcement.

What developers get

Developers get fewer mystery pipelines.

They can run one command locally and get the same shape of output that CI/CD will collect later. They do not need to remember where Dependency-Check writes reports or which SBOM task matters for a multi-module Spring Boot project.

They also get a workflow that respects their time. Fast checks happen in hooks. Heavier checks happen through the build. CI/CD verifies the result.

That is a much better experience than discovering every AppSec issue after a push.

What the security team gets

The security team gets consistency.

Reports arrive in predictable formats and paths. SonarQube analysis receives the metadata it needs. SBOM generation follows the same assumptions across services. Multi-module projects behave less like special snowflakes. CI/CD jobs become easier to audit because the security wiring is versioned in one build layer.

Most importantly, the team gets a better adoption story.

Instead of telling every service owner to copy another YAML block, AppSec can offer a build convention:

apply the plugin
set the project values
run securityAnalyze locally and in CI/CD

That is easier to scale.

The result

secure-build-gradle-plugin is not another scanner.

It is a way to make existing scanners usable in normal Java engineering.

The goal is not to move all security into Gradle. The goal is to put build-aware security checks in the build system, where developers can run them locally and CI/CD can reproduce them without copy-paste.

That is the pattern I want across Secure SDLC:

local where possible
build-aware where useful
CI/CD for enforcement

When that pattern works, security stops being a pile of pipeline scripts and becomes part of the engineering workflow.

Project links:

DEV Community: Nikolay Kuziev

Why Fixed Container Image Versions Matter: Lessons from the Trivy Supply Chain Attack

What happened with Trivy

The problem is not only latest

The task: controlled updates instead of silent updates

Why CI/CD images are high-trust dependencies

The bad pattern

A better pattern: fixed version

The stronger pattern: version plus digest

What the Trivy incident teaches here

But pinned images get old

CI/CD should not change without Git history

Dockerfile base images have the same problem

GitHub Actions need SHA pinning

What I would standardize in CI/CD

Example: GitLab CI with pinned Trivy image

Example: Docker run with digest

Example: Kubernetes workloads

How to detect the bad pattern

What I would block immediately

What I would allow temporarily

What pinning does not solve

The bigger CI/CD hardening picture

How this connects to my build tooling

Fixed versions vs fixed behavior

The workflow I prefer

A practical team policy

A simple checklist

What I learned from the Trivy incident

Closing

Related articles

References

Don't Let Secrets Become Commits: Bringing Gitleaks Into the Developer Workflow

The problem I kept running into

Why CI-only secret scanning is too late

The principle: security checks should run where the mistake happens

The local layer: pre-commit plus Gitleaks

I do not want this to become a README

Project-specific Gitleaks configuration

Where pre-commit ends and build tooling begins

CI/CD still stays in the design

What developers get

What the security team gets

The part that matters

Making Maven Builds Security-Aware: AppSec Checks Without CI/CD Drift

The problem I wanted to remove

Why the usual approach is inconvenient

The design principle

Why a Maven core extension

What runs under the hood

Configuration without forcing one style

Coverage should not require repeated wiring

SonarQube needs more than a token

Dependency-Check should produce one predictable shape

SBOM generation should describe the real artifact

Multi-module Maven projects need first-class handling

CI/CD becomes an execution layer

Where pre-commit and Gitleaks fit

What developers get

What the security team gets

The result

Stop Copy-Pasting Security YAML: A Gradle Build Layer for Java AppSec

The problem I ran into

Why CI/CD-only security wiring is uncomfortable

The design principle

The build tooling layer

What runs under the hood

Moving feedback before the merge request

SonarQube metadata belongs in conventions

Dependency-Check reports should be boring

SBOM output should describe the runtime artifact

Coverage wiring should not be tribal knowledge

Multi-module Gradle builds are where this pays off

CI/CD becomes smaller

Where pre-commit and Gitleaks fit

What developers get

What the security team gets

The result