Advisory shaped by the people writing the standards
Five practice areas, designed to move programs from intent to measurable outcomes. Most clients engage for a focused assessment, then continue with ongoing advisory or delivery oversight.
Software Bill of Materials (SBOM) and xBOM strategy
CycloneDX adoption, BOM quality, lifecycle, distribution.
Software Bill of Materials (SBOM) is now the default vocabulary of software transparency. A Bill of Materials (BOM) is a structured inventory of the components and relationships that make up a product. Most programs, however, treat it as an output artifact rather than a lifecycle asset. I help teams move from one and done exports to BOM as a strategic input to risk, procurement, incident response, and product management.
Typical scope
- Assess current BOM generation coverage and quality against the CycloneDX Authoritative Guide.
- Advise on generation, enrichment, signing, and distribution patterns for build and post build contexts.
- Guide expansion beyond SBOM into Cryptography Bill of Materials (CBOM), Artificial Intelligence Bill of Materials (AIBOM), Software as a Service Bill of Materials (SaaS-BOM), Operations Bill of Materials (OBOM), and Manufacturing Bill of Materials (MBOM).
- Shape vulnerability and exploitability transparency strategy across Vulnerability Disclosure Reports (VDR), Vulnerability Exploitability eXchange (VEX), and attestation workflows.
- Frame how teams should consume BOMs for vulnerability, policy, provenance, and license decisions.
- Develop the organizational playbook for internal consumers: legal, procurement, product security, incident response, and compliance.
Regulatory readiness
EU CRA first, with NIST SSDF, FDA, and the surviving US baseline.
The center of gravity has moved. The EU Cyber Resilience Act is now the most consequential software regulation in force, and it lands on every product manufacturer that ships into Europe. I translate abstract requirements into concrete engineering work, backed by primary sources and the standards that regulators cite.
EU Cyber Resilience Act (Regulation 2024/2847)
The CRA entered into force on December 11, 2024. Vulnerability reporting obligations begin September 11, 2026. Full conformity assessment kicks in December 11, 2027. Two annexes do most of the work.
- Annex I, Part I — secure by design. Products with digital elements must be designed, developed, and produced so they ensure an appropriate level of cybersecurity, with explicit obligations on secure defaults, attack surface minimization, and protection from unauthorized access. OWASP provides three frameworks that map cleanly onto these obligations: the Application Security Verification Standard (ASVS) for application security requirements, the Software Component Verification Standard (SCVS) for component and supply chain assurance, and the Software Assurance Maturity Model (SAMM) for program maturity. SCVS, which I co-authored, is referenced in its entirety by the NIST Secure Software Development Framework (SSDF).
- Annex I, Part II — SBOM and vulnerability handling. Manufacturers must produce a Software Bill of Materials (SBOM) in a commonly used and machine readable format covering at least top level dependencies, maintain it across the product lifecycle, and run a coordinated vulnerability disclosure process. CycloneDX, ratified as ECMA-424, is the international standard format that satisfies this requirement. Vulnerability Disclosure Reports (VDR) and Vulnerability Exploitability eXchange (VEX) provide the exploitability transparency that turns disclosure into something a downstream user can act on.
Other regulatory tracks
- Align engineering practices with the NIST Secure Software Development Framework (SSDF), published as Special Publication (SP) 800-218, and SP 800-218A for generative artificial intelligence.
- Interpret U.S. Food and Drug Administration (FDA) premarket cybersecurity guidance for medical device manufacturers, including SBOM and Secure Product Development Framework (SPDF) expectations under Section 524B of the Federal Food, Drug, and Cosmetic Act.
- Translate the surviving U.S. federal baseline into supplier evidence. Executive Order 14028 and Office of Management and Budget (OMB) Memorandum M-22-18 remain in force after the June 2025 rollback of EO 14144 enhancements via EO 14306, so federal agencies still collect and validate vendor attestations.
- Benchmark program maturity against the OWASP Software Assurance Maturity Model (SAMM), and verify component and supply chain assurance against the OWASP Software Component Verification Standard (SCVS).
- Prepare audit ready evidence packages covering generation, signing, retention, and distribution.
Supply chain hardening
Reduce risk across the software you build and consume.
Transparency is the foundation. Hardening is what you do with it. I work with product security, platform engineering, and open source program offices to translate supply chain visibility into real reductions in component risk, vulnerability exposure, and breach blast radius.
Typical scope
- Calibrate program requirements to risk tolerance using the OWASP Software Component Verification Standard (SCVS), which sets the high level control objectives for supply chain integrity.
- Threat model the supply chain path from source to production using established methodologies such as STRIDE, PASTA, or MAESTRO as appropriate.
- Guide OWASP Dependency-Track adoption and tuning for continuous component intelligence across large portfolios.
- Define vulnerability prioritization that considers exploitability, reachability, and blast radius rather than raw Common Vulnerability Scoring System (CVSS) severity.
- Establish open source contribution, consumption, and provenance policies that are realistic for the developer population.
- Advise on artifact provenance using Supply chain Levels for Software Artifacts (SLSA), in-toto, and signed attestations integrated with continuous integration and delivery (CI/CD) pipelines.
- Recommend hardening controls for the build environment, package registries, and release pipelines against tampering.
Executive advisory and training
Briefings, maturity assessments, private training, keynotes.
Not every organization needs a six month program. Many need a sharp, well informed conversation with someone who can distinguish genuine signal from vendor noise, and who can calibrate the message for board members, CISOs, and engineering directors alike.
Formats
- Board and executive briefings on supply chain risk, regulation, and strategic positioning.
- Program maturity assessments benchmarked to the OWASP SCVS, the NIST SSDF, and industry peer data.
- Private team training on Software Bill of Materials (SBOM), CycloneDX, Dependency-Track, Cryptography Bill of Materials (CBOM), and post quantum cryptography readiness.
- Workshop facilitation for cross team alignment on policy, tooling, and roadmap.
- Keynotes and conference sessions on supply chain transparency and its trajectory.
- Due diligence and vendor review support for M&A, procurement, or partnership decisions.
Artificial intelligence in the secure supply chain
AI supply chain transparency, AI assisted secure development, and agentic system safety.
Artificial intelligence (AI) has moved from a feature to a load bearing part of the supply chain. The models, datasets, embeddings, retrieval pipelines, and agentic tool integrations that ship inside products now carry their own provenance, license, exploitability, and regulatory exposure. At the same time, AI is becoming a force multiplier for the security work it once threatened to overwhelm. I advise on both sides of that equation.
AI supply chain transparency
Treat AI components with the same rigor applied to software dependencies. The CycloneDX Artificial Intelligence Bill of Materials (AIBOM) describes models, datasets, training and fine tuning data, hyperparameters, evaluation criteria, energy consumption, intended use, and known limitations in a machine readable form that downstream consumers can verify and act on. AIBOM is part of the broader CycloneDX (ECMA-424) specification, so the same toolchain that generates a Software Bill of Materials (SBOM) can also describe the AI surface area of a product.
AI assisted secure development
Agentic coding assistants are reshaping how secure work gets done. Used well, they accelerate threat modeling, secure code review, design review, and triage of supply chain concerns. Used poorly, they introduce silent regressions, hallucinated controls, and a confidence gap between what was reviewed and what was actually changed. I help teams build the workflows, guardrails, and review patterns that let them benefit from AI assistance without inheriting a new class of supply chain risk.
Secure by default for agentic systems
Building with agentic AI brings a new threat surface, from prompt injection and indirect prompt injection to tool misuse, untrusted Model Context Protocol (MCP) servers, data exfiltration through retrieval, and excessive agency in autonomous loops. The OWASP Top 10 for Large Language Model Applications, the OWASP AI Security Verification Standard (AISVS), and the MAESTRO threat modeling methodology provide structured ways to reason about these risks. I help product and platform teams adopt secure by default patterns so the agentic systems they ship hold up under adversarial conditions.
Regulatory alignment
AI work intersects an expanding regulatory perimeter. The EU Cyber Resilience Act (CRA) Annex I obligations on secure by design, secure defaults, and vulnerability handling apply to products with digital elements that incorporate AI. The EU Artificial Intelligence Act layers risk based obligations on top of that, with specific requirements for general purpose AI and high risk systems. The U.S. National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF) extends to generative AI through Special Publication (SP) 800-218A, and the NIST Artificial Intelligence Risk Management Framework (AI RMF) provides the governance scaffold. I translate these obligations into concrete engineering and documentation work rather than legal anxiety.
Typical scope
- Advise on adoption of an Artificial Intelligence Bill of Materials (AIBOM) practice using CycloneDX, covering models, datasets, embeddings, fine tuning data, and external service dependencies.
- Guide how agentic coding tools should be used inside the secure development lifecycle, including review gates, attestation of human oversight, and provenance of generated changes.
- Frame the threat model for agentic systems using STRIDE, PASTA, and MAESTRO, with attention to prompt injection, tool misuse, supply chain trust boundaries for Model Context Protocol (MCP) servers, and post incident forensics.
- Map product AI capabilities to the CRA Annex I obligations, the EU AI Act risk tiers, NIST SP 800-218A, and the NIST AI Risk Management Framework (AI RMF) to inform a single defensible compliance narrative.
- Benchmark application and model assurance against the OWASP Top 10 for Large Language Model Applications, OWASP AISVS, and the OWASP Machine Learning Security Top 10.
- Recommend secure coding and secure by default patterns for AI features, with practical guidance on input handling, output validation, retrieval trust, sandboxing, and least privilege for tool use.
Ready to take the next step?
Pick the path that fits. Schedule a working conversation, or send a quick email and I will reply personally.
A deliberate process, not a rubber stamp.
Every engagement follows roughly the same structure. The depth, duration, and deliverables flex to the situation.
-
Intake and alignment
A short call to understand your context, stakeholders, regulatory exposure, and internal pressure. I will tell you directly whether I am the right advisor and where to start if I am not.
-
Assessment
A focused review of your current state, typically two to six weeks. Interviews, artifact review, benchmark against the OWASP ASVS, OWASP SCVS, OWASP SAMM, BSIMM, and the NIST SSDF, and a written briefing for leadership.
-
Roadmap
A prioritized plan that sequences work across standards adoption, tooling, process, and communication. Designed to be usable by your engineering leadership without me in the room.
-
Execution support
Optional ongoing advisory during delivery. Office hours, design reviews, escalation support, and help preparing the evidence packages your team relies on when responding to regulators or customers.
-
Transition
Engagements are designed to make themselves obsolete. At close, your team owns the program, the evidence, and the institutional muscle to keep it current.
Not sure which service fits?
Send a short note describing your situation. I read every inquiry personally and respond with an honest recommendation, even if it points elsewhere.