Sectors

The same audit, aimed at whatever is actually forcing the question.

Almost nobody commissions an audit because they want one. There is a submission, a customer, a regulation or a transaction behind it — and that pressure decides what the report has to prove.

Automotive

Automotive & mobility

Vehicle software is distributed software: the code leaves your building inside a product the customer owns, which activates the obligations hosted teams never have to think about. Type approval regimes add a second requirement — the supplier chain has to be able to state its components, not just its suppliers.

  • Component inventories that survive a tier-one supplier chain, not just first-party code
  • Copyleft exposure in head units, telematics and gateway firmware
  • Source-offer positions for shipped ECUs and over-the-air updates
  • SBOM formats and depth aligned to cybersecurity management system expectations

Usually driven by

UN R155 / R156 cybersecurity and software update management, ISO/SAE 21434 programmes, and OEM supplier requirements pushed down the chain.

Medical

Medical devices

Device submissions now expect a software bill of materials with real support behind it: known components, known versions, a maintenance story for each, and the ability to answer what changed at the next submission. An SBOM assembled by hand for one filing will not survive the second.

  • Submission-grade SBOMs covering the device software and its build inputs
  • Component support status — maintained, end-of-life, unmaintained — stated per component
  • Licence obligations for software distributed on-device and in service tooling
  • Regeneration wired into the build, so the next submission is an artifact and not a project

Usually driven by

Premarket cybersecurity documentation for device submissions, hospital procurement security reviews, and post-market vulnerability handling.

Embedded

Embedded & connected products

Embedded builds are where audits find the most: a vendor board support package of unclear origin, a kernel tree with local patches, a busybox userland, and a toolchain nobody has rebuilt in years. Everything in that image is distributed to whoever buys the device.

  • Firmware image inventory, including base layers and vendor-supplied trees
  • Static linking analysis — where the obligation actually attaches
  • Written-offer and complete-corresponding-source positions for shipped devices
  • Product-level SBOMs suitable for market surveillance and enterprise buyers

Usually driven by

EU Cyber Resilience Act obligations for products with digital elements, enterprise procurement requirements, and copyleft compliance requests.

Software

Infrastructure & commercial open source

Companies built on their own open source carry a specific risk: the boundary between the community edition and the commercial one is a licensing boundary, and it erodes quietly as code moves between repositories. Add a bring-your-own-cloud deployment and hosted-only assumptions stop holding.

  • Community-to-commercial boundary review across shared components and monorepos
  • Obligations recalculated for customer-deployed and bring-your-own-cloud offerings
  • Inbound contribution and third-party licence hygiene in the public repositories
  • Portfolio-wide tiering so the audit lands on what ships first

Usually driven by

Enterprise customer reviews, a licence change or relicensing decision, a funding round, or the first on-premises deployment.

Investors

Investors & acquirers

A code audit in diligence is not a box to tick — it is the one check that can change what the buyer is permitted to do with the asset. Copyleft in a product the acquirer plans to distribute differently is a live issue, and it is almost never in the target's own disclosures.

  • Deal-clock scoping with an interim read before the full report
  • Exposure assessed against the acquirer's intended distribution model
  • Derived-code detection included by default
  • Findings written to be read by counsel and by the deal team

Usually driven by

Signed letters of intent, growth rounds, portfolio reviews, and sell-side preparation ahead of a buyer's own audit.

Regulation

What each regime actually asks you to produce.

A short map of the requirements that turn an audit from good practice into a deadline. Specific obligations depend on your product and market — this is where the conversation starts, not legal advice.

Regime Who it reaches What it wants to see
EU Cyber Resilience Act Products with digital elements sold into the EU Component inventory, vulnerability handling, support-period commitments
UN R155 / R156 Vehicle type approval and the supplier chain behind it Managed software inventory, update integrity, supplier evidence
Device premarket cybersecurity Medical device submissions Software bill of materials with support status per component
Federal software attestation Software sold to US federal agencies Secure development attestation, SBOM on request, provenance
Enterprise procurement Anyone selling to a large security organization SBOM per release, licence disclosure, remediation commitments

Tell us what is forcing the deadline.

A submission, a customer questionnaire, a regulation coming into force, or a signed letter of intent — the driver decides the scope, and the scope decides everything else.

Scope an audit