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:

• Secure Build Maven Extension
• Secure Build Gradle Plugin