A Composer manifest field that loads specified files immediately when vendor/autoload.php is executed. Because the files run during bootstrap rather than on demand, any malicious code placed there can act before normal application logic or user-facing controls begin.
Expanded Definition
In Composer, autoload.files is a manifest field that points to PHP files which are executed as soon as vendor/autoload.php is loaded. In NHI and application security terms, that makes it a bootstrap-time execution path, not a lazy import mechanism. Any code placed there runs before most application-level checks, routing, or user interaction, so it can initialize helpers, register functions, or quietly alter runtime behaviour.
Definitions vary across vendors when the topic shifts from build-time dependency wiring to security review, but the security concern is consistent: bootstrap code is trusted by default and often receives less scrutiny than business logic. NHI Management Group treats this as part of the broader problem of secrets and executable logic being embedded in early startup paths, especially when service accounts, API keys, or environment bootstrapping are involved. The concept is adjacent to autoload class maps, but it is more sensitive because included files execute immediately rather than only when a symbol is referenced. The most common misapplication is using autoload.files for convenience scripts that also manipulate secrets or network calls, which occurs when developers treat startup code as harmless configuration.
Examples and Use Cases
Implementing autoload.files rigorously often introduces a small performance and review burden, requiring teams to weigh faster bootstrap convenience against a larger attack surface and harder code auditing.
- A framework loads a helper file through autoload.files to define global utility functions used across multiple packages.
- A legacy application loads compatibility code at startup so older modules continue to work while refactoring is underway.
- A malicious dependency inserts code into an autoloaded file so the payload runs before normal request handling begins.
- A security team reviews startup files for hardcoded tokens after finding secrets referenced during bootstrap in code paths that load through Composer.
- Organisations compare Composer startup behaviour with guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls to determine whether code inclusion is justified and controlled.
For broader NHI context, the Ultimate Guide to NHIs explains why early execution paths matter when credentials, service accounts, and automation trust are involved. This becomes especially relevant when build pipelines generate the vendor tree and teams assume dependency installation is equivalent to code review. In practice, autoload.files is used for legitimate bootstrap logic, but it should be treated as executable trust, not a passive metadata feature.
Why It Matters in NHI Security
autoload.files matters because it creates a privileged execution point that can run before defensive controls are fully active. In NHI environments, that is dangerous when files touched during bootstrap can read secrets, initialize API clients, or set up impersonation flows for service accounts. If a package, plugin, or internal library is compromised, bootstrap code can become the first and quietest place an attacker gains execution. The risk is compounded in CI/CD and container builds, where a dependency change can propagate into production without a human ever opening the file that executes.
This is why NHI Management Group highlights secret exposure and identity sprawl as systemic issues. The Ultimate Guide to NHIs notes that 96% of organisations store secrets outside secrets managers and 79% have experienced secrets leaks, which is exactly the kind of environment where startup code can turn a minor dependency issue into identity compromise. Teams should map bootstrap files to the same review standard used for privileged scripts, because trust in early execution often outlives the original author’s intent. Organisations typically encounter the consequence only after a dependency update or supply chain incident, at which point autoload.files becomes operationally unavoidable to investigate.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST SP 800-63, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Bootstrap-loaded files can hide or expose secrets before normal controls begin. |
| NIST CSF 2.0 | PR.DS-1 | Early-executing files can store or disclose data, including credentials and tokens. |
| NIST SP 800-63 | Identity assurance is weakened when code can initialize trust before verification logic. | |
| NIST Zero Trust (SP 800-207) | Zero Trust rejects implicit trust in code paths that execute before policy enforcement. | |
| NIST AI RMF | Bootstrap logic can affect AI-enabled systems by shaping early execution and data access. |
Classify bootstrap code paths and protect any data they touch with the same rigor as production secrets.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 20, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
