AMM xBOM Sentinel

• 

• 

• 

• 

• 

• 

• 

• 

• 

• 

Inspiration

Modern software repositories contain far more security-relevant evidence than a traditional dependency list can show. They may include software packages, AI-related libraries, cryptographic components, algorithm references, multiple language ecosystems, and configuration evidence distributed across manifests, lockfiles, source files, and documentation.

At the same time, organizations are beginning to prepare for post-quantum cryptography, but many still lack a reliable inventory of where cryptography appears in their software supply chain. Existing SBOM generation is useful, but an SBOM alone does not explain whether declared dependencies are sufficiently resolved, whether classical and post-quantum algorithm references coexist, or whether security-relevant evidence changed after a baseline was established.

I created AMM xBOM Sentinel to help close that evidence gap. The objective was not to build another dashboard or claim automated compliance. It was to create a local-first, repository-focused security tool that produces transparent, machine-readable evidence that developers and security teams can investigate.

This is an independent solo project conceived, scoped, and directed by Alessandra Monteiro Martins.

What it does

AMM xBOM Sentinel analyzes supported repository evidence and generates:

• a CycloneDX JSON SBOM;
• dependency and component evidence across supported ecosystems;
• AI- and cryptography-related component classifications;
• explicit cryptographic algorithm evidence;
• a conservative post-quantum cryptography diagnostic;
• declared-versus-resolved evidence reconciliation;
• a repository baseline;
• a machine-readable comparison of evidence drift;
• investigation-oriented findings with stable identifiers.

The current release supports evidence from:

• Python pyproject.toml;
• Node.js package.json and package-lock.json;
• PHP composer.json and composer.lock;
• Maven pom.xml;
• .NET PackageReference entries in .csproj files.

Generated evidence is written under the repository’s .amm-xbom directory. Source content remains read-only by default.

The project can be used through:

• a Python CLI;
• an installable Codex plugin;
• a Codex Skill;
• a local MCP server;
• a repository-local plugin marketplace;
• a composite GitHub Action.

The local MCP server exposes tools for repository analysis, baseline creation, and baseline comparison. This allows Codex to invoke the product directly while preserving the same evidence and path contracts used by the CLI.

How I built it

I began by defining the product boundaries, evidence model, supported ecosystems, security assumptions, output contracts, and acceptance criteria. Given the hackathon timeline and the resources available to a solo developer, I deliberately prioritized a focused and defensible version 0.1.0. Additional capabilities and refinements are planned for future releases.

The architecture was intentionally designed as local-first. The shipped product does not call an OpenAI API at runtime. For security, reproducibility, and resource-efficiency reasons, repository analysis is deterministic and based exclusively on locally available evidence.

The implementation was developed as a sequence of validated stages:

The implementation was developed as a sequence of validated stages:

1. safe repository discovery;
2. supported manifest and lockfile parsing;
3. CycloneDX SBOM generation;
4. AI and cryptographic component classification;
5. explicit algorithm-evidence extraction;
6. conservative PQC diagnostics;
7. declared-versus-resolved reconciliation;
8. baseline and drift comparison;
9. CLI and local MCP integration;
10. Codex Skill and plugin packaging;
11. GitHub Action integration;
12. canonical packaged PQC rules;
13. deterministic demonstration and release hardening.

The final demonstration uses a synthetic multi-ecosystem repository. It produces an initial analysis, creates a baseline, introduces one controlled cryptographic-evidence change, and compares the updated repository against that baseline. The resulting drift artifact reports drift-review-required and the stable finding identifier XBOM-DRIFT-007.

The project includes a prebuilt Python wheel, SHA-256 verification, Apache-2.0 licensing, attribution metadata, and a reproducible judge workflow that does not require rebuilding the package from source.

How I Used GPT-5.6 and Codex

This was a human-directed, AI-assisted engineering process.

Before the hackathon, I had already been developing related ideas for my professional portfolio, consulting services, and future career opportunities. I brought those ideas into structured discussions with GPT-5.6 in ChatGPT Web to refine the problem statement, define a realistic product MVP, and challenge my initial assumptions.

I originated the product concept and selected and supplied the relevant domain standards, security models, and technical references. I defined the scope and exclusions, established the evidence model and security boundaries, and retained final authority over the architecture, priorities, acceptance criteria, and release decisions.

During the initial planning stage, I used GPT-5.6 in ChatGPT Web, first with medium and later high reasoning, to examine creator-defined ideas, review public documentation, cross-check competition requirements, organize the roadmap, identify technical and delivery risks, and strengthen the implementation plan.

I began the repository work on Windows using GitHub Desktop and VS Code. During this initial stage, GPT-5.6 in ChatGPT Web helped define the architecture, repository structure, acceptance plan, and implementation sequence. It also generated portions of the initial code and project scaffolding, which I manually transferred into VS Code, reviewed, tested, corrected, and integrated into the repository.

As the codebase and architecture became more stable, repository-level implementation moved into Codex with GPT-5.6. Codex then supported broader implementation, refactoring, environment and dependency configuration, feature expansion, regression testing, defect diagnosis, documentation, packaging, and security hardening.

Every requested action and generated change was manually reviewed and approved by me. I used VS Code for independent source-code and diff auditing, while ChatGPT Web with GPT-5.6 provided additional analysis and cross-verification of changes produced in Codex and reviewed in VS Code. GitHub Desktop was used for controlled commits and pushes. Through the GitHub Web interface, I monitored GitHub Actions workflows and clean Ubuntu validation, inspected repository and commit status, reviewed tags and artifacts, and verified release readiness.

GPT-5.6 and Codex accelerated research, planning, initial code generation, implementation, testing, diagnosis, and verification. Product authorship, domain expertise, supervision, review, acceptance, and final decisions remained with me.

Challenges

1 Keeping the scope realistic The original problem space could easily expand into runtime monitoring, vulnerability scanning, CI/CD discovery, complete AI BOM generation, CryptoBOM lifecycle management, automatic remediation, and regulatory certification. For the hackathon release, I deliberately constrained the product to defensible repository evidence. Features not implemented are stated clearly rather than implied.

2 Conservative Security Interpretation

Cryptographic names found in source files or documentation do not necessarily prove runtime use. Similarly, the absence of an algorithm reference does not prove that the algorithm is absent from a deployed system. The diagnostic therefore treats findings as investigation signals, not as vulnerability findings or compliance conclusions.

3 Cross-platform path behavior

A particularly useful defect appeared only in clean Ubuntu CI. The SBOM writer returned a repository-relative path while other artifact writers returned absolute paths. An ignored Windows workspace artifact had hidden the inconsistency locally. The issue was corrected, and regression coverage was added so that generated artifact paths are absolute, existing, and contained within the analyzed repository.

4 Packaging and reproducibility

The plugin, Skill, CLI, MCP server, packaged PQC rules, wheel metadata, licensing files, console entry points, and deterministic demonstration all needed to remain consistent across source execution, wheel installation, Codex integration, and GitHub Actions.

The final wheel was independently installed in a clean Python 3.12 environment. Its declared dependencies were resolved from the Python Package Index, pip check reported no broken requirements, and the complete demonstration passed using the installed wheel.

5 Time and resource constraints

The project was built by one person within a short hackathon schedule, using the Codex capacity available through a Plus plan and without a separate API budget. This required deliberate sequencing: stabilize the architecture first using chat gpt web 5.6, and than use Codex only where repository-level implementation and validation provided the highest value, and manually approve every operation.

What I learned

I learned that useful software supply-chain security evidence depends as much on contracts and limitations as on detection logic.

A trustworthy tool must clearly distinguish:

• declared dependencies from resolved evidence;
• textual references from proven runtime behavior;
• static evidence from deployment state;
• investigation findings from vulnerabilities;
• technical signals from compliance conclusions.

I also learned that deterministic fixtures, stable finding identifiers, clean-environment installation tests, cross-platform CI, and explicit output-path contracts are essential when building security tooling intended for both humans and AI-assisted developer workflows.

Most importantly, integrating a tool with Codex is not only about exposing a command. The Skill, MCP tools, package, documentation, and generated evidence must all guide the agent toward the same safe and reproducible operating model.

Current boundaries

AMM xBOM Sentinel currently provides static repository evidence. It does not claim:

• complete runtime visibility;
• production monitoring;
• private-key extraction;
• automatic remediation;
• complete vulnerability scanning;
• regulatory or compliance certification;
• a complete standalone AI BOM;
• a complete standalone CryptoBOM.

Absence of evidence is not proof of absence. Findings should be reviewed together with architecture, deployment, build, and operational evidence.

What’s next

Future work may extend the evidence model toward additional ecosystems, ingestion of existing SBOM and AI BOM documents, CI/CD evidence, richer CryptoBOM generation, vulnerability correlation, repository history analysis, and architecture-oriented PQC migration recommendations.

The foundation of version 0.1.0, however, is intentionally focused: reproducible, local, machine-readable software-supply-chain and PQC evidence for developers, security teams, and Codex.

Built With

• 5.6sol
• aicomponentclassification
• baselinemanagement
• chatgpt
• cli
• codex
• codexplugin
• cryptography
• cyclonedx
• dependencyanalysis
• developertools
• drifdetection
• evidencereconciliation
• githubactions
• json
• mcpserver
• modelcontextprotocol
• openai
• opensource
• phyton
• postquantumcriptography
• sbom
• security
• softwaresupplychainsecurity
• staticanalysis