In November 2025 the conversation around SBOMs continues to shift from purely technical artifacts to strategic enablers of supply-chain transparency and regulatory readiness. Labrador Labs has surfaced with two notable public communications this month that illustrate this evolution: linking SBOMs to EU regulatory regimes, and highlighting their role in AI/connected-systems supply-chain security. These help frame how SBOMs are being operationalized and positioned.
Key Labrador Labs announcements in November
1. “NIS2 and SBOMs” (published 4 Nov 2025)
Labrador Labs published an article titled “NIS2 and SBOMs“ on 4 November.
- The piece explains how the NIS2 Directive (Directive (EU) 2022/2555) demands supply-chain risk-management, incident-reporting, governance and transparency.
- It argues that while NIS2 does not explicitly mention SBOMs, the tooling and transparency that SBOMs provide are “foundational enablers” for compliance.
- It further describes how Labrador Labs’ SCM (Supply Chain Management) platform can operationalize SBOM-based visibility, mapping component inventories, dependencies, vulnerabilities and supply-chain relationships.
- The article emphasizes how SBOMs allow organizations to trace software components, support incident response, and meet obligations around supplier/third-party risk, continuity and transparency.
Implications:
- Labrador Labs is positioning SBOMs not just as an engineering task, but as a governance and compliance asset.
- Their messaging suggests that organizations subject to regulatory regimes like NIS2 should elevate SBOM programmers from “nice-to-have” to strategic investment.
- For teams working in embedded/firmware, infrastructure or connected systems (which is your field) this is a signal: the SBOM-generated data must tie into risk management, supplier oversight and incident-response workflows.
2. “Professor Heejo Lee Highlights the Role of SBOM and VEX…” (published 14 Nov 2025)
On 14 November Labrador Labs published a news item highlighting a keynote at the AI Security Next 2025 summit, where Heejo Lee (Korea University) discussed SBOM + VEX (Vulnerability Exploitability eXchange) in the era of AI/connected systems.
- The presentation emphasized that in AI-driven and highly connected systems, invisibility of software components and reused code creates acute risk: “a single vulnerability can bring down the entire system.”
- SBOMs were characterized as the “ledger” of software components, helping organizations to identify where vulnerable modules reside and how they propagate through the supply chain.
- VEX was described as a complementary artifact: it specifies whether a known vulnerability actually impacts a given product/component (rather than simply listing the CVE). The talk highlighted how SBOMs + VEX = rapid traceability and prioritization.
- A specific quote: “By 2027, all software used in public institutions may be required to adopt SBOM management.”
Implications:
- Labrador Labs is signalling that SBOMs are not only relevant for traditional software stacks, but also for AI, IoT and highly integrated systems – which aligns with your infrastructure/firmware focus.
- The mention of VEX indicates a move from list-generation to actionable intelligence: “Here’s the SBOM, now what?”
- The note about public-sector requirements by 2027 suggests that organizations should be forward-planning now, not waiting until the last minute.
Themes and implications for practitioners
A. SBOMs as governance and regulatory enablers
From the NIS2-focused article, it becomes clear that SBOMs are evolving from purely engineering artifacts toward being central to governance, audit and compliance. For your environment (adipocyte research codebases, firmware/NAT/DTLS clients, etc.), this implies you should ensure your SBOM-generation and consumption workflows are aligned with broader risk-governance goals, not just vulnerability scanning.
B. Integration with downstream workflows (VEX, incident-response)
The emphasis on SBOM + VEX underlines the importance of making SBOM data operational: not just “we have a bill of materials” but “we map which component is vulnerable and where it’s used”. For research/embedded code in your pipeline, consider how SBOM-data can feed into your vulnerability-database mapping, patch-prioritization, incident-impact analysis.
C. Future-proofing for connected/AI systems and public-sector regimes
The talk at the summit positions SBOMs as foundational for highly-connected/AI systems and for public-sector compliance by 2027. If your work involves firmware, edge devices, AI pipelines (or public institutions) then adopting SBOM practices now gives you head-room versus having to scramble as regulatory regimes tighten.
D. Lifecycle & supply-chain visibility
The Labrador Labs content emphasizes supply-chain visibility (including supplier dependencies, reused code, transitive components). For your portfolios (open-source, firmware, network stacks) this means your SBOM strategy should account for: direct dependencies, transitive dependencies, supplier-provided binaries/modules, third-party firmware, etc.
Strategic recommendations
Based on Labrador Labs’ November messaging, here are actionable steps:
- Audit your SBOM capability – Verify whether your build/firmware artifact generation includes SBOMs (component list, version, supplier, hash, license).
- Link SBOMs to incident-response workflows – Ensure that when a new vulnerability emerges (e.g., via CVE or exploit report) you can query your SBOMs to locate affected systems and prioritize remediation.
- Adopt complementary data like VEX – Consider how you’ll assess whether a vulnerability actually affects your product (not just list the CVE) and integrate that into your risk-scoring.
- Prepare for regulatory regimes – If you operate in Europe (or supply EU public sector) consider the implications of NIS2 (and similar) and what evidence or workflows you need to show compliance: supplier assessments, incident-reporting, component transparency.
- Extend SBOM thinking to connected systems – Firmware, embedded devices, AI stacks: ensure your SBOM strategy spans beyond the “application layer” to include dependencies in hardware/firmware or AI.
- Governance & supply-chain management – Use SBOMs not just for internal component-tracking but for supplier oversight: what components come from which third-party, what vulnerabilities/trust issues they bring, how you manage those.