Millions of Parts, No Map of the Whole

Modern software systems are composed of millions of components from thousands of sources — open-source libraries, commercial modules, third-party APIs, transitive dependencies — but no science of safe composition exists to predict whether a system built from individually assessed components will be secure when assembled. Software Bills of Materials (SBOMs), now mandated by Executive Order 14028 (2021), provide component inventory but cannot evaluate whether component combinations create emergent vulnerabilities. Security evaluations of individual components cannot be reused across different system contexts because security properties do not compose: a component proven secure in one configuration may introduce vulnerabilities in another.

Software supply chain attacks — SolarWinds (2020), Log4j (2021), XZ Utils (2024) — have demonstrated that a single compromised component can cascade across thousands of organizations and millions of systems. The NASEM report identifies that SBOMs provide only "a hint of potential security issues" while the actual composition problem remains unsolved. Critical infrastructure (power grids, water systems, financial networks, healthcare) runs on software stacks where no organization has complete visibility into the security properties of the assembled whole. Open-source projects, which underpin most critical infrastructure software, rely on volunteer maintainers — many projects critical to global infrastructure are maintained by one or two individuals with insufficient code review capacity.

SBOMs document component inventories but cannot express compositional security properties — they list ingredients without predicting whether the recipe is safe. Static analysis tools (Snyk, Dependabot, OWASP Dependency-Check) scan individual components for known vulnerabilities (CVEs) but miss novel vulnerabilities and cannot analyze inter-component interactions. Dependency pinning and reproducible builds address supply chain integrity (ensuring you get what you asked for) but not security (whether what you asked for is safe in combination). The combinatorial space of component interactions is intractable with current methods: a system with 1,000 components has millions of pairwise interactions and billions of higher-order interactions.

Compositional security reasoning frameworks that allow security evaluations to compose — if component A is secure under assumptions X and component B is secure under assumptions Y, formal methods to determine what can be said about their combination. Automated tools for detecting dangerous inter-component interactions: API misuse patterns, trust boundary violations, implicit assumption conflicts, and shared-state race conditions. Scalable metrics for evaluating open-source component trustworthiness based on maintainer activity, review coverage, dependency freshness, and historical vulnerability patterns — going beyond binary "known-vulnerable vs. not-known-vulnerable."

A student team could analyze a specific open-source software stack (e.g., a common web application framework like Express.js or Django with its typical plugin ecosystem) to map implicit trust assumptions between components and identify composition points where security properties may break. Alternatively, teams could build a prototype tool that goes beyond SBOM inventory to flag dangerous dependency patterns — abandoned libraries, single-maintainer bottlenecks, inconsistent trust boundaries, or components with incompatible security assumptions. Relevant disciplines: computer science, software engineering, cybersecurity, formal methods.