A Project Object Model, or POM, is the XML configuration file that defines a Maven project. It describes the project structure, dependencies, goals, and build behaviour, giving teams a central place to control how the application is compiled, packaged, and maintained.
What a POM does in Maven
A Project Object Model is the central configuration that Maven reads to understand a project’s identity, structure, dependencies, plugins, and build lifecycle. It is the source of truth for how the application should be compiled, tested, packaged, and released.
Because the POM drives build behaviour, small changes can have broad effects. A dependency version update can change runtime behaviour, a plugin change can alter test execution or artifact generation, and inherited parent configuration can reshape the entire build across modules.
Core POM elements and inheritance
A POM is not just a list of libraries. It typically includes coordinates such as groupId, artifactId, and version, plus dependency declarations, plugin configuration, properties, repositories, and module relationships. In multi-module builds, the parent POM often defines shared defaults so child modules stay consistent.
This inheritance model is powerful, but it also means the effective build is the result of several layers of configuration. Teams need to understand what is defined locally, what is inherited, and what is being overridden, especially when debugging why one module behaves differently from another.
Why the POM matters for build integrity
The POM directly affects software supply chain integrity because it determines which code is pulled in, which plugins run, and which steps are trusted during the build. If dependency versions are loose, repositories are uncontrolled, or plugin settings are altered unexpectedly, the build can become harder to reproduce and easier to tamper with.
For that reason, the POM is often treated as a controlled engineering artifact rather than a convenience file. Treating it as part of the release process helps teams reason about provenance, repeatability, and whether the build they intended is the build they actually shipped.
Common POM usage patterns and pitfalls
Teams often use the POM to centralise dependency management, standardise plugin versions, and share build defaults across modules. That makes it easier to scale a Java codebase, but it can also hide important behaviour in parent files, imported BOMs, or transitive dependencies.
Common pitfalls include version drift, dependency conflicts, plugin misconfiguration, and accidental inheritance of settings that were meant only for one module. A POM can look simple while still producing a complex effective build, so reading the resolved configuration matters as much as reading the source file.
Risk and Threat Considerations
The main risk with a POM is that it controls what your build consumes and how it executes. A compromised dependency, malicious plugin update, or unexpected change in inherited configuration can affect every downstream artifact produced from that project.
Failure mechanism: Attackers and supply-chain failures exploit the trust placed in dependency declarations, repositories, and build plugins, especially where versions are weakly pinned or review of build changes is inconsistent.
Impact: The result can be dependency confusion, hidden malicious code in the build path, corrupted artifacts, or a production release that no longer matches the intended source state.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8 provides the primary governance reference for this term.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 4 — Secure Configuration of Enterprise Assets and Software | POMs define build and software configuration that should be hardened and controlled. |
| CIS 16 — Application Software Security | POMs influence dependency and plugin selection in application builds. | |
| Recommendation — Harden and review POM-driven build settings to prevent unsafe software configuration changes. Validate Maven dependencies and plugins as part of application software security. | ||
Practitioner Guidance
Why practitioners should care: Treat the POM as a governed control point, not just a developer convenience file. It is where build reproducibility, dependency selection, and plugin behaviour are encoded, so changes deserve review with the same discipline used for other high-impact configuration.
Common misunderstanding: Teams sometimes focus only on source code and overlook build files as an integrity boundary. In practice, the build definition can be just as important as application code because it shapes the final artifact and the trust chain behind it.
Related resources from NHI Mgmt Group
- When should organisations choose local NVMe, shared file storage, or object storage for model weights?
- Why does a target object based security model change how teams assess compliance and implementation effort?
- What are the signs that a chatbot project is becoming too tightly coupled to one model or framework?
- How should security teams implement API security as a continuous operating model instead of a one-time project?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
