Topic: compliance
-
Audit logs: what to record, how to keep them intact, and who may read them
An audit log answers who did what to which object, when and with what result; it is written by the application for every security-relevant action, kept separate from debug logs, protected against alteration by moving it promptly to append-only or write-once storage, and read only under recorded, restricted access.
-
Preparing a manufacturer's CRA vulnerability workflow: intake, evidence and reporting clocks
A proposed preparation protocol connects vulnerability intake and component records to the CRA reporting decision. It separates the reporting duty already applicable in 2026 from the wider vulnerability handling requirements applicable in December 2027.
-
Checking an operating system's support lifecycle before automating against it
Automating patch, upgrade or compliance workflows against a host that has already passed end-of-life produces false confidence: no more security fixes are coming regardless of what the automation reports. This methodology lists where each major vendor publishes lifecycle dates and how to fold an EOL check into a pre-flight step.
-
Choosing an open-source licence
Permissive licences (MIT, Apache-2.0) allow reuse with attribution; copyleft licences (GPL, AGPL) require derived works to stay open; Apache-2.0 adds a patent grant. Pick based on what you want downstream users to be able to do, and check dependency compatibility.
-
Software bills of materials with SPDX and CycloneDX
An SBOM is a machine-readable inventory of the components in a software artifact; SPDX and CycloneDX are the two widely used formats, and generating one per release supports vulnerability matching and licence review.
-
CRA reporting since September 2026: triggers, deadlines and the Single Reporting Platform
The CRA requires manufacturers to report actively exploited product vulnerabilities and severe product security incidents. Both have 24-hour and 72-hour stages, but their final reports run from different events.
-
Software bills of materials (SBOM): the inventory of your own supply chain
A software bill of materials lists, in machine-readable form, which components in which versions are contained in a delivered artifact. SPDX (ISO/IEC 5962:2021) and CycloneDX (OWASP) are the common formats; an SBOM is generated per release from the built artifact, stored alongside it, and used to check against vulnerability reports and license obligations. Together with provenance attestations (SLSA), it makes the supply chain verifiable.
-
CIS Benchmarks and DISA STIGs as a hardening baseline: what they are and how to apply them selectively
CIS Benchmarks and DISA STIGs are two independently maintained sets of configuration recommendations; both offer selectable profile levels rather than one fixed target. Applying a profile wholesale without recording exceptions is a common way hardening work breaks a production service.
-
Swiss cyberattack reporting and the CRA: different duties for operators and product manufacturers
Swiss critical-infrastructure reporting concerns qualifying cyberattacks on covered operators. The CRA concerns product manufacturers supplying the EU market, including Swiss manufacturers; similar early deadlines do not make the recipients or reporting triggers interchangeable.
-
CRA and open source: distinguishing contributors, manufacturers and stewards
An open-source licence does not by itself determine CRA duties. The regulation distinguishes commercial product supply, contributions to software outside a contributor's responsibility, and sustained support by open-source software stewards, whose Article 24 duties start in December 2027.
-
Scanning a Linux host against a baseline with OpenSCAP
oscap xccdf eval runs a SCAP Security Guide profile against a live host or an offline image and writes a human-readable report; reviewing the generated remediation script before running it is what keeps an automated scan from becoming an automated outage.
Machine-readable: JSON