Launch is day one. For security too.

The code you did not write

A modern corporate website is rarely written from scratch. It relies on a CMS, extensions, JavaScript libraries, PHP packages, third-party services for forms, analytics or maps. A typical installation pulls in hundreds of dependencies, most of which are never read by the team deploying them.

OWASP, the reference foundation for application security, has taken note of this reality. In its Top 10 presented in November 2025, the “Software Supply Chain Failures” category appears in third position. It extends the former category of vulnerable or outdated components to the whole chain: dependencies, build systems, integration and deployment pipelines, update mechanisms. Another signal: security misconfiguration rises to second place, just behind broken access control.

These two categories have something in common. They have less to do with a badly written line of code than with the way a system is assembled, configured and maintained.

When a dependency becomes an attack vector

September 2025 provided a large-scale demonstration. A worm named Shai-Hulud spread through npm, the JavaScript package registry. After compromising a maintainer’s account, it published booby-trapped versions of their packages, harvested the access tokens and keys present on developers’ machines and in pipelines, then used that access to infect other packages. The US cybersecurity agency CISA reported more than 500 compromised packages. Several security vendors then documented a second wave at the end of November.

The lesson goes beyond the JavaScript ecosystem. Any platform that automatically installs the latest version of a component implicitly trusts the security of the account of every maintainer in the chain. The protective measures are known and unspectacular: pin versions, review updates before deploying them, limit the secrets available to pipelines, enforce strong authentication on publishing and deployment accounts.

What the law already requires in Switzerland

Since 1 April 2025, the Information Security Act has required operators of critical infrastructure to report cyberattacks to the Federal Office for Cyber Security (NCSC) within 24 hours of their discovery. The scope is broad: energy, drinking water, transport, health, finance, but also cantonal and municipal authorities. Missing information can be supplemented within 14 days. Since 1 October 2025, failure to report has been punishable by a fine of up to CHF 100,000. After six months, the NCSC had received 164 reports.

The revised Data Protection Act, in force since September 2023, requires for its part that any breach of data security likely to result in a high risk for the persons concerned be reported to the Federal Commissioner (FDPIC) as soon as possible.

In practice, an organisation must be able to answer three questions quickly after an incident: what happened, which data are affected, who must be informed. Without usable logs or a written procedure, 24 hours go by very fast.

The Cyber Resilience Act, or software treated as a product

In the European Union, the Cyber Resilience Act (Regulation (EU) 2024/2847) has passed a first milestone. Since 11 September 2026, manufacturers of products with digital elements must report actively exploited vulnerabilities and severe incidents through ENISA’s single reporting platform, which opened the same day. The deadlines are tight: an early warning within 24 hours, a full notification within 72 hours, then a final report.

The regulation covers software and hardware placed on the European market: applications, downloadable software, connected devices, components sold commercially. A website operated as a service is not, in principle, a “product” within the meaning of the text. A mobile app, an extension sold or software delivered to European customers, on the other hand, can be. Swiss manufacturers selling in the EU bear the same obligations as their European competitors. Full application of the regulation, with CE marking, will follow on 11 December 2027.

For software publishers and agencies developing digital products, the question becomes very practical: for each product, who holds the manufacturer role, and who monitors vulnerabilities throughout the support period?

What this changes for a web platform

Even outside the scope of the Cyber Resilience Act, these texts outline a de facto standard. A serious platform is expected to know its components, maintain them and know how to react. In practice, this translates into a few concrete deliverables.

• An up-to-date inventory of components and their versions, ideally as an SBOM (software bill of materials) generated at every build.

• A planned update policy, with a defined lead time for security patches and a test environment to validate them.

• A hardened and verified configuration: security headers, least privilege, named administrator accounts protected by strong authentication.

• Logging and monitoring that make it possible to reconstruct an incident.

• A written incident procedure, with contacts, roles and the applicable reporting obligations.

• Backups whose restoration is actually tested.

None of these measures is new. What changes is that they can no longer be postponed until “after launch”. A public platform is exposed from the moment it goes live, and the legal framework now assumes these reflexes exist.

This article presents a general framework and does not constitute legal advice.

Frequently asked questions

Is my corporate website affected by the Cyber Resilience Act?

A website operated as a service is not, in principle, a product within the meaning of the regulation. Applications, software or extensions placed on the EU market can be, including when they are developed in Switzerland. A case-by-case analysis remains necessary.

Who must report a cyberattack to the NCSC?

Operators of critical infrastructure as defined by the Information Security Act, including cantonal and municipal authorities, within 24 hours. Other organisations may report an incident voluntarily.

What is an SBOM?

A software bill of materials: the list of components, libraries and versions that make up an application. It lets you know quickly whether a newly published vulnerability affects you.