source code
third-party libraries
transitive dependencies
build plugins
base container images
OS packages
generated code
CI runners
artifact repository
container registry
deployment manifests
runtime configuration

Can we trust what we build, what we ship, and what we run?

A production deployment should be traceable from running pod back to image digest, build pipeline, source commit, dependency set, SBOM, and approval gates.

JDK distribution
Maven wrapper
Maven plugins
parent POM
BOMs
third-party dependencies
internal libraries
generated API clients
annotation processors
Docker base image
OS packages
CI runner image
build scripts
Helm charts / manifests
GitOps controller
registry policies

A safe-looking PR changes only pom.xml.
It upgrades a minor library.
That library pulls a vulnerable transitive dependency.
The build passes.
The runtime now exposes a vulnerable parser.

direct dependency
transitive dependency
dependency scope
plugin dependency
parent POM
BOM
version mediation
exclusions
dependencyManagement

<dependency>
  <groupId>some.group</groupId>
  <artifactId>some-lib</artifactId>
  <version>LATEST</version>
</dependency>

<dependency>
  <groupId>some.group</groupId>
  <artifactId>some-lib</artifactId>
  <version>[1.0,)</version>
</dependency>

pinned versions
centralized dependency management
approved internal BOM
dependency convergence checks
explicit exclusions with reason
regular vulnerability review

Why is this dependency needed?
Is it already provided by platform/runtime?
Does it duplicate an existing library?
What transitive dependencies does it bring?
Is it maintained?
What is its license?
Does it run code at build time or runtime?

mvn dependency:tree
mvn dependency:tree -Dincludes=org.apache.logging.log4j
mvn dependency:analyze

known CVE
abandoned library
unexpected license
duplicate classpath
version conflict
shadowed dependency
incompatible jakarta/javax namespace
runtime-provided dependency packaged accidentally

wrong Jackson provider version
mixed javax/jakarta APIs
HK2/Jersey version mismatch
Servlet API packaged incorrectly
validation provider mismatch

library A requires jackson-databind 2.x
library B pulls older vulnerable jackson-databind
Maven chooses one based on mediation rules
runtime behavior changes silently

dependency convergence
duplicate classes
upper bound dependency check
banned dependencies
allowed repositories
plugin version lock

<rules>
  <dependencyConvergence />
  <requirePluginVersions />
  <requireReleaseDeps />
</rules>

Check whether Maven Enforcer is used.
Check whether dependency convergence is enforced.
Check whether banned dependencies exist.
Check whether internal BOM controls versions.

known vulnerabilities
license issues
malware indicators
outdated packages
policy violations

pom.xml
resolved dependency graph
JAR/WAR artifact
container image filesystem
SBOM

A CVE finding is not automatically exploitable.
But it is not automatically irrelevant either.

affected package
affected version
fixed version
runtime reachability
exposed attack surface
compensating controls
upgrade risk
exception owner
exception expiry

mark as false positive forever with no evidence
ignore because tests pass
upgrade blindly without compatibility review

A vulnerable XML parser is high severity.
If the service accepts untrusted XML, risk is high.
If XML support is not used and dependency is unreachable, risk may be lower.

"not used" must be proven, not guessed.

no provider registered
no endpoint consumes XML
dependency only test scope
class not packaged in runtime artifact
feature disabled by config

classify
prioritize
fix or mitigate
record exception with expiry
verify in pipeline

What dependencies are in this artifact?
What versions?
What licenses?
Which package coordinates?
Which artifact/image contains them?

incident response
CVE impact analysis
license review
customer/security audits
release traceability
supply chain provenance

CycloneDX
SPDX

resolve dependencies
generate SBOM
scan SBOM
attach SBOM to build artifact
attach SBOM to container image/release
store SBOM in artifact repository or security platform

Is SBOM generated per commit, per release, or per image?
Does SBOM include transitive dependencies?
Does it include container OS packages?
Where is it stored?
Can production image digest be mapped to SBOM?

base OS packages
shell/tools if present
CA certificates
JDK/JRE files
native libraries
package manager metadata
entrypoint scripts

OS package CVEs
language package CVEs
malware signatures
secrets accidentally baked into image
unsafe file permissions
root user
known vulnerable base image

use minimal base image
run as non-root
avoid package managers in final image
avoid shell if not needed
pin base image by digest where policy requires
regularly rebuild for patched base images
scan before push/deploy
block critical findings unless exception approved

Who owns the base image?
How often is it patched?
Is it approved for production?
Does it include JDK or JRE?
Does it include a shell?
Does it run as root by default?
Does it include CA certificates?
Is it compatible with Java 17?

FROM openjdk:latest

FROM registry.example.com/platform/java17-runtime@sha256:...

fewer packages
smaller image
fewer CVEs
less shell-based post-exploitation capability

harder interactive debugging
need better logs/metrics/traces
need separate debug image or ephemeral debug container
CA/timezone/native dependency issues can surprise teams

Minimal images are good only if operations and debugging workflows are mature enough.

Check whether platform standard requires distroless/minimal.
Check how production debugging is done without shell.
Check whether ephemeral debug containers are allowed.

Was this artifact produced by a trusted build identity and not modified afterward?

JAR/WAR
container image
SBOM
attestation/provenance metadata
Helm chart
release bundle

registry tampering
artifact substitution
untrusted build output
manual upload bypass

cluster admits only signed images
signature identity is trusted
signature maps to approved pipeline
attestation includes source/build info
exceptions are controlled

Where did this artifact come from?

source repository
commit SHA
branch/tag
build pipeline ID
builder identity
build timestamp
materials/dependencies
artifact digest
SBOM reference
signing identity

this image was built from commit X
this build ran tests Y
this artifact passed scan Z
this SBOM belongs to image digest D

running pod -> image digest -> signature -> attestation -> pipeline -> commit -> PR -> approval

untrusted runner
mutable build environment
secrets exposed to PRs
pipeline step skipped
manual artifact upload
branch protection bypassed
unreviewed workflow changes

protected branches
required reviews
required checks
pinned actions/plugins/images
least-privilege pipeline tokens
separate build and deploy identities
no long-lived secrets in CI if possible
immutable build artifacts
artifact promotion instead of rebuild per environment

OpenAPI generated clients/servers
AsyncAPI generated event models
protobuf/gRPC generated stubs
MapStruct generated mappers
JPA/MyBatis generator output

generator version drift
unsafe generated deserialization
large generated diff hides contract change
generated code committed without source contract update
client generated from stale contract

pin generator version
generate in CI
check generated code freshness
review source contract first
scan generated dependencies

build pulls directly from public internet
multiple unmanaged repositories
snapshot dependencies in release
HTTP repository URLs
local developer machine publishes release artifact

internal artifact proxy/repository
approved external repositories
checksum validation
blocked snapshots for release
immutable releases
artifact retention policy
malware scanning

settings.xml mirrors
repository credentials
plugin repositories
snapshot policy
release policy

Check whether builds use internal artifact repository.
Check whether direct Maven Central access is allowed.
Check whether plugin repositories are governed.

source code
unit test fixtures
Dockerfile ARG/ENV
image layers
Maven settings
CI logs
build artifacts
SBOM metadata
helm values
GitOps manifests

ARG TOKEN
RUN curl -H "Authorization: Bearer $TOKEN" https://example.com/private-artifact

use build secret mechanism
use short-lived CI identity
avoid copying credential files into image
scan repository and image for secrets

registry/app:1.2.3        -> tag
registry/app@sha256:abc   -> digest

same tag points to different image later
rollback does not restore exact artifact
scan result no longer matches deployed content

build produces immutable image digest
scan/sign digest
GitOps deploys digest or tag pinned to digest according to platform standard
runtime inventory records digest

Check whether Kubernetes manifests use tags or digests.
Check whether deployment records image digest.
Check whether release notes map version to digest.

only signed images allowed
only approved registries allowed
block root containers
require non-root user
require read-only root filesystem where possible
block privileged pods
require resource limits
require vulnerability policy pass

Kubernetes admission controller
OPA/Gatekeeper
Kyverno
cloud policy engine
platform deployment gate
GitOps policy

Which policies are enforced at deploy time?
Which are only advisory reports?
Who can override them?
Are overrides audited and expiring?

small regular dependency upgrades
automated PRs with CI
compatibility tests
contract tests
performance smoke tests
clear owner for exceptions
emergency patch path for critical CVEs

Jersey version alignment
HK2 version alignment
Jackson provider compatibility
Jakarta vs javax namespace
Servlet API compatibility
validation provider compatibility
PostgreSQL JDBC driver behavior
Kafka client behavior

1. Identify affected package/version.
2. Identify affected artifacts/images/services.
3. Check whether package is runtime, test, plugin, or base image.
4. Assess exploitability from service exposure.
5. Find fixed version or mitigation.
6. Patch and run tests.
7. Scan again.
8. Release through safe rollout.
9. Record exception if not patched immediately.
10. Track expiry and customer/security communication if required.

license type
internal policy compatibility
transitive license
copyleft risk
commercial restriction
unknown license

Check license scanning tool.
Check policy for allowed/blocked licenses.
Check exception process.
Check whether generated SBOM includes license metadata.

timestamps inside JAR
unlocked dependency versions
remote generated content
non-pinned plugins
system-dependent file order
local machine build differences

Maven wrapper
pinned plugin versions
locked dependency versions
controlled build image
no dynamic versions
build metadata separated from binary content where possible

which service version is deployed?
which image digest?
which commit?
which dependencies?
which SBOM?
which config version?
which cluster/namespace?
which signing identity?

metadata:
  labels:
    app.kubernetes.io/name: quote-api
    app.kubernetes.io/version: "1.2.3"
  annotations:
    build.commit: "abc123"
    build.pipeline: "pipeline-456"
    image.digest: "sha256:..."

SCA flags a library not visible in pom.xml

transitive dependency from another library

upgrade parent library
add dependencyManagement override
exclude and replace dependency
remove unused library

application code unchanged, image scan fails

base image OS package vulnerability

rebuild with patched base image
switch approved base image
remove unnecessary OS package
request time-bound exception if not exploitable and no fix exists

SBOM exists but cannot be mapped to production pod

SBOM generated for JAR but not image
image rebuilt later
tag moved
release metadata missing

attach SBOM to image digest
record digest in deployment
avoid mutable tag-only release evidence

cluster runs image without trusted signature

admission policy missing or bypassed
manual deploy path
registry exception

enforce signature at admission
remove bypass
use exception workflow with audit and expiry

build passes but endpoint fails at startup/runtime

Jersey/HK2/Jackson/Jakarta version mismatch

align BOM
run integration tests
check provider registration
verify runtime dependency tree

scanner detects token/API key in image layer

Docker build ARG/ENV, copied config, CI credential leakage

revoke secret immediately
rebuild clean image
remove secret from build process
scan image layers

1. Identify artifact: source dependency, plugin, JAR, image OS package, or secret.
2. Identify scope: compile/runtime/test/provided/plugin/base image.
3. Identify version selected by actual build.
4. Trace why it is included.
5. Check fixed version or policy exception.
6. Assess runtime exposure.
7. Patch or document exception.
8. Verify scan passes or exception is recorded.

mvn dependency:tree
mvn dependency:tree -Dverbose
mvn help:effective-pom
docker image inspect <image>
docker history <image>

kubectl get pod <pod> -o jsonpath='{.status.containerStatuses[*].imageID}'
kubectl describe pod <pod>

[ ] New dependency has clear purpose.
[ ] Existing approved library cannot already solve the same problem.
[ ] Version is pinned or controlled by BOM.
[ ] Transitive dependencies are reviewed.
[ ] Dependency scope is minimal.
[ ] License is acceptable.
[ ] Vulnerability scan is clean or exception is documented.
[ ] Jakarta/Jersey/HK2/Jackson/Servlet compatibility is considered.
[ ] Maven plugin versions are pinned.
[ ] No dynamic versions like LATEST or open ranges.
[ ] No direct unapproved repository added.
[ ] Docker base image is approved.
[ ] Image runs as non-root.
[ ] No secrets are baked into image or logs.
[ ] SBOM is generated and attached if required.
[ ] Image scan passes policy.
[ ] Artifact/image signing path is preserved.
[ ] Provenance links artifact to source commit and pipeline.
[ ] Runtime deployment uses immutable artifact identity according to platform standard.
[ ] Policy exceptions are time-bound and owned.

[ ] What SCA/vulnerability scanning tool is used?
[ ] Is scanning done on source, resolved dependencies, artifacts, container images, or all of them?
[ ] Is SBOM required for Java artifacts or container images?
[ ] Which SBOM format is required: CycloneDX, SPDX, or another?
[ ] Where are SBOMs stored?
[ ] Can a production pod/image digest be mapped to an SBOM?
[ ] Is Maven Enforcer or equivalent dependency governance used?
[ ] Is there an internal BOM or parent POM standard?
[ ] Are dynamic dependency versions banned?
[ ] Are plugin versions pinned?
[ ] Are direct public repositories allowed or must builds use internal artifact proxy?
[ ] What is the approved Java 17 base image?
[ ] Are distroless/minimal images used internally?
[ ] Are images scanned before push, before deploy, or both?
[ ] Are critical/high findings blocking or advisory?
[ ] What is the exception process for scanner findings?
[ ] Are exceptions time-bound and reviewed?
[ ] Are container images signed?
[ ] Are signatures enforced at deployment/admission time?
[ ] Is provenance/attestation generated?
[ ] Is deployment based on image tag, digest, or both?
[ ] How are build artifacts promoted across environments?
[ ] Are release artifacts rebuilt per environment or promoted immutably?
[ ] Are CI/CD pipeline definitions protected by review?
[ ] Are CI secrets scoped and protected from untrusted PRs?
[ ] Are generated clients/server stubs checked for freshness and generator version pinning?
[ ] Are dependency upgrades automated, manual, or centrally managed?

A dependency change is a production risk change.
A base image is a dependency.
A build plugin is executable code in your supply chain.
A tag is not identity; a digest is closer to identity.
A scan without enforcement is advisory, not control.
A signature without admission policy is evidence, not prevention.
An SBOM that cannot map to production is inventory, not response capability.
A vulnerability exception without expiry becomes permanent risk.
A generated client without generator governance becomes hidden supply chain drift.

standardized
traceable
automated
enforced
observable
reviewed
exception-managed