Software Integrity
Build, signing, provenance, vulnerability state and the evidence needed to trust software across its lifecycle.
Browse all 13 analyses →Questions this collection helps you examine
- Which software state is actually deployed and supported?
- What proves the provenance and authorisation of a release?
- How are compatibility, rollback and supplier responsibilities demonstrated?
Each analysis keeps the incident evidence, deployment assumptions and practical decision together. Use the collection to compare cases across sectors.
Analysis, newest first
All decision collections →Automotive OTA Patch Assurance Depends on Virtual Tests, Physical Evidence and Supplier Authority
Virtual ECU testing can accelerate incident response only when hardware evidence and supplier signing responsibilities are resolved.
Prepare supplier signing and evidence interfaces before exploitation, calibrate virtual results to hardware, and release through risk-based physical gates followed by controlled monitoring.
Cisco NX-OS needs two different exposure checks
Cisco NX-OS advisories require separate checks for feature exposure and fixed-release coverage. Disabling NGOAM does not resolve the broader hardening advisory.
Assess the relevant feature state, select an upgrade covering applicable advisories and verify the running release.
An SBOM Does Not Prove That Automotive Vulnerability Management Works
Inventory tells you what may be present. Assurance starts when detection, applicability, product scope and remediation can be connected to evidence.
Test the complete vulnerability decision path across tools, products, versions and suppliers instead of treating SBOM generation as the control objective.
Modicon M580 Shows Why the Application Baseline Can Be a Security Boundary
CVE-2026-3869 can affect Modicon M580 and M580 Safety when a project with a lower application level is running. Firmware inventory alone may therefore fail to prove the actual cybersecurity state of the deployed controller.
Treat the running application level as part of the Modicon M580 cybersecurity baseline. Verify it after download, restore, replacement and commissioning, and route safety-relevant changes through the appropriate impact-analysis and validation process before return to service.
Espressif Shows Why Secure Boot Assurance Depends on the Flash Attack Path
AR2026-006 shows that affected ESP32 SoCs can accept invalid ECDSA signatures in ROM-based Secure Boot. Exploitation still requires the attacker to replace the signed image in flash, making storage access and manufacturing configuration part of the real assurance argument.
Evaluate Secure Boot as an end-to-end boot trust path. Record the immutable ROM behavior, the attacker's ability to modify flash, the configured hardware protections and the feasible migration path as separate pieces of evidence.
SIMATIC S7-1500 MFP Shows Why an Embedded Linux Subsystem Needs Its Own Assurance Case
Siemens SSA-019113 tracks inherited Linux vulnerabilities in the GNU/Linux subsystem of the SIMATIC S7-1500 MFP. The assurance challenge is managing a second software lifecycle inside the same controller boundary.
Manage the additional GNU/Linux subsystem as an explicit software component inside the PLC assurance case. Track its version and inherited vulnerabilities separately, then reconnect that evidence to the controller's actual network reachability and process authority.
Airwall Shows Why a Hardcoded Key Becomes a Lifecycle Problem
CVE-2026-64887 in Johnson Controls Airwall is a local hardcoded-key vulnerability. The broader engineering lesson is that embedded cryptographic secrets become lifecycle dependencies once products are deployed at scale.
Treat cryptographic secrets as lifecycle-managed assets, not constants in source code. Prefer unique or bounded credentials, protect provisioning, design rotation and revocation before SOP, and prove that field recovery remains possible when the original trust material can no longer be trusted.
A Trusted Automotive Update Path Can Become the Malware Delivery Path
Kaspersky found a multi-stage Android malware chain delivered through built-in firmware update mechanisms on automotive head units. The deeper product-security problem is what happens when legitimate update authority becomes part of the attack path.
Treat automotive update infrastructure as product-security authority: protect release approval, distribution identities, signing and provenance separately, and design a recovery path that does not depend on the same service whose trust may have been lost.
A Valid Signature Does Not Make Vulnerable Firmware Safe
Signed AAOS firmware can remain authentic while carrying exploitable dependencies, turning vulnerability remediation into a lifecycle and supply-chain governance problem.
Treat firmware signing as one evidence layer, and contract for the practical capability to remediate vulnerable software across the full vehicle lifecycle.
A VEX Statement Is a Claim That Needs Evidence
VEX can suppress false urgency, but an unsupported “not affected” status simply converts vulnerability noise into governance risk.
Use VEX as a signed-off exploitability decision backed by evidence, not as a bulk suppression mechanism.
How a Software-Defined Vehicle Could Inherit Compromise Before Delivery
This engineering scenario examines how compromised flashing, signing or cryptographic provisioning could establish an incorrect software or identity baseline before delivery.
Treat flashing and provisioning as product-security release controls with end-to-end provenance.
When Legitimate Engineering Workflows Can Carry Malicious Control Logic
OpenPLC research demonstrates malicious modification of the running user program. Compromise of source, repositories or build infrastructure is a separate engineering risk that requires its own evidence.
Protect logic provenance end to end: verify approved source, build context and deployed program without presenting toolchain compromise as an observed OpenPLC finding.
Euro 7 Turns Emissions Compliance into a Cybersecurity Evidence Chain
When regulatory evidence depends on sensors, ECUs, onboard monitoring and off-board data, integrity has to survive the complete chain.
Treat Euro 7 evidence as a product-security asset with end-to-end provenance, not merely as telemetry.