Project-level linting

Expanded Definition

Project-level linting is a policy-as-code approach that packages API and security rules inside the project so they run automatically during authoring, review, and update workflows. In NHI and IAM programs, it is used to catch unsafe patterns early, such as hard-coded secrets, overly broad permissions, missing rotation requirements, or unauthorised identity references before they are merged or deployed. This differs from centralised governance controls that only evaluate assets after they reach a platform gate or production environment.

Definitions vary across vendors on how much linting belongs in developer tooling versus deployment pipelines, but the operational goal is consistent: shift policy checks left without losing enforcement strength. NHI Management Group treats project-level linting as a repeatable control layer, not a substitute for runtime monitoring or approval workflows. When aligned to NIST Cybersecurity Framework 2.0, it reinforces preventative governance by making secure identity patterns the default. The most common misapplication is treating linting as a documentation aid, which occurs when teams generate warnings but do not block unsafe changes.

Examples and Use Cases

Implementing project-level linting rigorously often introduces friction in developer workflows, requiring organisations to weigh faster feedback and consistency against setup effort and occasional false positives.

• A platform team embeds rules that reject API keys committed to source control, so service accounts are not created with embedded long-term secrets.
• An infrastructure repository validates that every NHI must use approved naming, ownership metadata, and rotation tags before changes are merged.
• A CI pipeline flags permissions that exceed least-privilege baselines, especially where a project tries to grant broad access across cloud projects.
• A security team uses the same rule set across repositories so policy checks remain consistent between application code, templates, and deployment definitions, as described in the Ultimate Guide to NHIs.
• A cloud engineering group lint-checks new automation against identity standards before deployment, complementing guidance from NIST Cybersecurity Framework 2.0.

Why It Matters in NHI Security

Project-level linting matters because NHI failures are often created long before an attacker arrives. When identity rules are enforced only by manual review, teams miss drift, copy unsafe patterns across projects, and allow risky credentials or privileges to survive repeated edits. NHI Management Group research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations, which makes author-time detection especially important for preventing exposure in code and CI/CD assets. Linting also supports broader governance goals by making control expectations visible to every contributor, not just security reviewers. That is particularly relevant where service accounts, API keys, and automation tokens outnumber human identities and carry excessive privilege.

Used well, linting turns policy into a project habit rather than a periodic audit event. Organisations typically encounter the cost of missing lint controls only after a leaked credential, failed deployment, or privilege escalation reveals that unsafe identity patterns were replicated across repositories, at which point project-level linting becomes operationally unavoidable to address.

Related resources from NHI Mgmt Group

• When does AI agent access become a board-level security concern?
• What is the difference between network trust and request-level identity trust?
• How should security teams keep identity security from becoming a pure IT project?
• What is the difference between scope-based authorization and object-level authorization in MCP?