The build path stops being a passive dependency list and becomes an execution surface. A jar can run code during compilation through service discovery, even if no source imports it and no install hook exists. That is why processor-path review, not just package intake, has to be part of supply-chain governance.
What Breaks in the Build Chain When Review Stops at the Package List?
Allowing annotation processors on the build path without review breaks the assumption that dependencies are passive. The build tool can discover and execute processor code during compilation, so a seemingly ordinary jar becomes part of the trusted execution surface. That shifts governance from package intake to build-time code execution control.
Why Annotation Processors Change the Trust Boundary
An annotation processor is not just metadata support. It can read source, generate code, influence compiled output, and interact with the build environment before a binary is even produced. If it is reachable through the build path, the review question is no longer only “what libraries do we ship?” but “what code can run while we are still building?”
That distinction matters because build systems often treat the compile classpath as a convenience layer, not a privileged execution zone. In practice, service discovery and processor auto-loading can let code run without an explicit import in source, which means the absence of an install hook or runtime dependency does not make the code harmless. The build path therefore needs the same kind of control discipline that teams already apply to other trusted execution surfaces.
What Review Has to Cover Beyond Package Intake
Processor-path review has to check more than provenance and version pinning. Teams need to know whether a jar contains processors, what those processors are allowed to inspect or generate, whether they are expected in that repository or module, and whether they introduce hidden code generation, source rewriting, or data exfiltration opportunities during compilation.
This is also where supply-chain governance gets specific. A build artifact may be acceptable as a library and still be unacceptable as a compile-time executor. If your review process only approves packages at intake, you can miss the moment where a dependency becomes active code. SLSA is relevant here because build provenance and build-step integrity are exactly what keep hidden execution paths from slipping into the release process.
The same logic applies to secure development maturity: teams that want a controlled build chain need explicit rules for generated code, compiler plugins, and other build-time extensions. OWASP SAMM is a useful reference point for making those review and governance practices part of the delivery lifecycle rather than an ad hoc release decision.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
SLSA, OWASP SAMM and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| SLSA | Supply chain integrity and build provenance | Annotation processors turn build steps into execution surfaces that SLSA is meant to harden. |
| Recommendation — Require provenance checks and restrict build-step execution to approved inputs. | ||
| OWASP SAMM | Software assurance maturity | Processor-path review is a software delivery governance practice that SAMM directly supports. |
| Recommendation — Embed build-time extension review into secure development and release governance. | ||
| NIST SP 800-53 Rev 5 | CM-5 — Access Restrictions for Change | Build-path approval is a change-control issue because processors alter compilation behavior. |
| SI-7 — Software, Firmware, and Information Integrity | Unreviewed processors can inject or alter generated code during the build. | |
| Recommendation — Restrict and approve build-step changes before they can affect released artifacts. Validate build outputs and block unapproved code-generation paths. | ||
| ISO/IEC 27001:2022 | A.8.9 — Configuration management | Build path composition is a controlled configuration that affects release integrity. |
| Recommendation — Manage build-path entries as controlled configuration items and review changes. | ||
Practitioner Guidance
What to verify: Separate ordinary compile dependencies from anything that can execute during compilation. Require a review step for processor discovery, not just dependency approval, and confirm whether the processor is expected for that module before allowing it onto the build path.
Decision rule: If a jar can run code while building, treat it as an execution-capable component and apply stronger controls than you would for a passive library. If the processor is unnecessary, exclude it from the build path rather than hoping it remains inert.
Common mistake: Teams often trust the package list because no source imports the jar directly. That is the wrong trust signal when service-loaded processors can act before runtime and can shape the artifact that gets released.
Practitioner takeaway: The control objective is not “review every dependency equally,” it is “identify every place where build-time execution can occur and govern it as code execution.”
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 12, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org