Advisory shaped by the people writing the standards.
Four 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.
- Design generation, enrichment, signing, and distribution pipelines for build and post build contexts.
- Expand beyond SBOM into Cryptography Bill of Materials (CBOM), Machine Learning Bill of Materials (ML‑BOM) for artificial intelligence systems, Software as a Service Bill of Materials (SaaS‑BOM), Operations Bill of Materials (OBOM) for runtime environments, and Manufacturing Bill of Materials (MBOM) for hardware.
- Deliver vulnerability and exploitability transparency through Vulnerability Disclosure Reports (VDR, sometimes called Vulnerability Advisory Reports or VAR), Vulnerability Exploitability eXchange (VEX) documents, and attestation workflows so disclosures carry useful context rather than noise.
- Operationalize BOM consumption: correlation with vulnerabilities, policy, provenance, and license obligations.
- Build the organizational playbook for internal consumers: legal, procurement, product security, incident response, and compliance.
Regulatory readiness
EU CRA, NIST SSDF, FDA, EO 14028, and sector specific mandates.
The regulatory map is now crowded. Programs are either ahead of their obligations or discovering them during an audit. I translate abstract requirements into concrete engineering work, backed by primary sources and the standards that regulators cite.
Typical scope
- Map your current program to the EU Cyber Resilience Act (CRA, Regulation 2024/2847), including technical documentation, conformity assessment routes, and vulnerability handling obligations.
- 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 Software Bill of Materials (SBOM) and Secure Product Development Framework (SPDF) expectations.
- Translate U.S. Executive Order 14028 and Office of Management and Budget (OMB) Memorandum M‑22‑18 attestation requirements into supplier and internal evidence.
- Benchmark program maturity against the OWASP Software Component Verification Standard (SCVS), which is referenced in its entirety by the NIST SSDF.
- 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 (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege), PASTA (Process for Attack Simulation and Threat Analysis), or MAESTRO (a multi agent threat modeling framework for AI systems) as appropriate.
- Stand up and tune OWASP Dependency‑Track 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.
- Verify artifact provenance using Supply chain Levels for Software Artifacts (SLSA), in‑toto, and signed attestations integrated with continuous integration and delivery (CI/CD) pipelines.
- Harden 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.
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 SCVS 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 direct contribution to evidence packages when regulators or customers come asking.
-
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.