The EU Cyber Resilience Act: what it means and who needs to prepare

What the CRA is, in one paragraph

The Cyber Resilience Act (CRA) is the European Union's first law that sets security requirements for almost every product with software in it.¹ It is "horizontal", which means it is not limited to one sector such as healthcare or banking. If what you sell runs code and connects to a device or a network, directly or indirectly, it is probably covered.²

Before the CRA, product security in Europe was a patchwork. Some sectors had their own rules, but a smart doorbell, a piece of accounting software or a desktop client could be sold in the EU without meeting any common security baseline. The CRA changes that. It puts the responsibility on the businesses that make, import and sell these products, not on the people who buy them.

I updated this article in November 2026, because one part of the law is no longer coming. It is here. Since 11 September 2026, manufacturers have to report actively exploited vulnerabilities and severe incidents.¹ The rest of the regulation applies from 11 December 2027.

The dates, and where things stand now

The CRA was published in the Official Journal on 20 November 2024 and entered into force 20 days later, on 10 December 2024.¹ It then switches on in three steps.

• 11 June 2026: the rules for conformity assessment bodies (the independent testers some products will need) started to apply.¹
• 11 September 2026: the reporting duty started. That date has passed, so if you are a manufacturer in scope, the obligation is live today.¹
• 11 December 2027: everything else applies, including the security requirements themselves, the documentation and the CE marking.¹

One detail catches people out. The reporting duty is not limited to new products. It applies to every product in scope, including those placed on the market before December 2027.³ The software you shipped in 2025 counts.

Worked example: which dates bite for a Cork thermostat maker

An example: Fota Heating, an invented company in Cork, sells a smart radiator thermostat, a mobile app to control it and a cloud API the app talks to. Its first model went on sale to customers in Ireland and the rest of the EU in 2025.

1. Today, 8 November 2026, the reporting duty already applies to that 2025 model, because Article 69(3) extends the reporting duty to products placed on the market before December 2027.³
2. The full security requirements do not yet apply to the 2025 model. Under Article 69(2) they reach older products only if they are substantially modified from 11 December 2027.³
3. A second model planned for spring 2028 must meet every requirement before it goes on sale, because it is placed on the market after 11 December 2027.

So Fota needs a reporting process now and a full compliance programme for anything it launches from December 2027.

What counts as a product with digital elements

The regulation's term is "product with digital elements": a software or hardware product, its remote data processing solutions, and software or hardware components placed on the market separately.² It covers products whose intended or reasonably foreseeable use includes a data connection to a device or network.²

"Remote data processing" is the part people miss. It is data processing at a distance, designed by or for the manufacturer, without which the product could not perform one of its functions.² The recitals give a direct example: when a mobile app needs an API or database provided by the manufacturer's own service, that service is in scope as remote data processing.⁴

The Commission's guidance, published on 27 July 2026, draws the line clearly.⁵ Software that is downloaded, installed or supplied to the user and runs on the user's side is a product with digital elements, and that includes browser extensions and desktop apps built with web technologies.⁶ A web application used only through a browser is not, unless it supports the functionality of a product with digital elements.⁶ A website that simply presents information is not a product either.⁶

Some products are excluded because other EU laws already cover them, for example medical devices, in vitro diagnostics, motor vehicles, certified aviation products and marine equipment, along with products made only for national security or defence.⁷

Worked example: three businesses, three answers

An example: three invented businesses ask whether the CRA reaches them.

1. Shannonside Ledger, a Limerick bookkeeping SaaS used only in the browser. Nothing is installed on the customer's side and it supports no physical product. On the guidance's own example, it is not a product with digital elements.⁶ It is outside the CRA.
2. Shannonside Ledger then launches a desktop sync client that customers install. That client runs on the customer's machine, so it is a product with digital elements.⁶ The server API the client needs to work is remote data processing and comes into scope with it.²
3. Fota Heating from the first example. The thermostat (hardware with embedded software), the app and the cloud API that controls the thermostat are all in scope, the API as remote data processing.⁴

The same company can sit both outside and inside the CRA, product by product. The test is never "are we a software company". It is "what exactly do we supply, and where does it run".

Pure SaaS, NIS2, and the gap between them

A pure web SaaS, with nothing installed by the user, is generally not a product with digital elements.⁶ The recitals point cloud services, including Software as a Service, to the NIS2 Directive instead.⁴

There is a nuance the old version of this article skipped. NIS2 applies to cloud computing providers that are medium sized or larger.⁴ A small browser only SaaS may therefore sit outside both. That is not a licence to be careless, because the GDPR still applies to the personal data it holds, but it does mean the regulatory question is different. I cover NIS2 itself in the NIS2 Directive explained.

The moment a SaaS ships something to the user's device, the picture changes. A mobile app, a desktop client, a browser extension or a plugin is a product with digital elements, and the backend it needs comes along as remote data processing.⁴⁶

Who carries which duty

The CRA assigns duties by role in the supply chain.⁸

• The manufacturer develops or manufactures the product, or has it made, and markets it under its own name, whether for payment, monetisation or free of charge. It carries the main obligations.⁸
• The importer is established in the EU and places on the EU market a product bearing the name of someone established outside the EU. It must check that the manufacturer has done the conformity assessment and met the requirements.⁸
• The distributor makes the product available without changing it, acting with due care, and checks among other things that it carries the CE marking.⁸

What this means for an Irish business

The CRA is a regulation, not a directive, so it is binding in its entirety and directly applicable in every member state, Ireland included.¹ There is no Irish Act to wait for and no Irish version of the rules to compare against. An Irish company that sells an app, a device or an installable plugin is covered on the same terms as one in Germany or France.

Where you report follows where you are established. A manufacturer notifies the CSIRT of the member state where it has its main establishment in the EU, and the regulation sets out a fallback, by reference to an authorised representative, importer, distributor or users, only for manufacturers with no main establishment in the EU.⁹ The main establishment is where the decisions on product security are predominantly taken.⁹ For a manufacturer that takes those decisions in Ireland, the fallback never comes into it. Its coordinating CSIRT is the Irish one.

In Ireland that is the National Cyber Security Centre (NCSC), which includes the State's national CSIRT.¹⁰ The NCSC published its own guidelines on the Article 14 reporting duty, dated 31 August 2026. They confirm that notifications go through the Single Reporting Platform to the national CSIRT and ENISA at the same time, that an email to the CSIRT is not a formal notification, and that products already on the EU market are in scope for reporting whenever they were launched.¹¹

Worked example: a Kilkenny shop that sells connected gadgets

An example: Marble City Gadgets, an invented online shop in Kilkenny, sells smart plugs from a German manufacturer to customers in Ireland and Germany. The plugs are products with digital elements. Marble City did not make them, so its duties are the supply chain ones: before listing a product it should see the CE marking and the documentation the regulation requires, and it should stop selling a product it has reason to believe does not comply.⁸

Because both the shop and the manufacturer are established in the EU, and the shop sells the plugs under the manufacturer's name without changing them, Marble City is a distributor on the regulation's definitions.⁸ The facts are not always that tidy. If the shop starts sourcing plugs from a maker outside the EU, or puts its own brand on them, its role can change, and that is a solicitor's view to get before the first order ships. I would not guess at that for a client, and I will not guess at it here.

Open source: who is in, who is out

Open source gets careful treatment. Free and open source software is in scope only when it is made available in the course of a commercial activity.¹² Software that is not monetised by its manufacturer is not treated as a commercial activity, and receiving donations or contributions from companies does not on its own make it commercial.¹²

The regulation creates a lighter role, the open source software steward: a legal person, such as a foundation, that supports open source products intended for commercial use on a sustained basis.¹² Stewards must have a documented cybersecurity policy and cooperate with authorities, and fines do not apply to them.¹²¹³

The part that matters for most businesses is the other side. If you build a commercial product on open source components, you must exercise due diligence when integrating them so they do not compromise your product, explicitly including components not made available commercially.¹⁴ If you find a vulnerability in one, you report it to whoever maintains it.¹⁴ The gems in your Gemfile are part of your product.

What the CRA actually requires

The essential requirements sit in Annex I, in two parts.¹⁵

Part I covers the product itself. Based on a documented risk assessment, a product must be placed on the market without known exploitable vulnerabilities, with a secure default configuration, with a way to fix vulnerabilities through security updates, with protection against unauthorised access, with encrypted or otherwise protected data, processing only the data it needs, with a limited attack surface, and with a way for users to delete their data and settings, among 13 points in total.¹⁵

Part II covers how you handle vulnerabilities, in eight points.¹⁵ You must:

• identify and document components, including a software bill of materials (SBOM) "in a commonly used and machine readable format covering at the very least the top level dependencies"
• fix vulnerabilities without delay, and keep security updates separate from feature updates where technically feasible
• test and review security regularly
• publish information about fixed vulnerabilities once the update is out
• have a coordinated vulnerability disclosure policy and a contact address for reports
• distribute updates securely, and security updates free of charge (unless otherwise agreed with a business user for a tailor made product)

You must also name a single point of contact so users can reach you quickly, including to report vulnerabilities.¹⁶

The support period is a minimum, not a maximum

The old version of this article said the support period was a maximum of five years. That was wrong, and I have corrected it. The support period must reflect how long the product is expected to be in use, and it must be at least five years, unless the product is expected to be in use for less than that.¹⁷ Each security update must then stay available for at least 10 years after it is issued, or for the rest of the support period if that is longer.¹⁷

Worked example: setting the support period for a thermostat

An example: Fota Heating expects people to keep a radiator thermostat on the wall for about ten years. That expectation is the example's assumption, chosen because heating controls are rarely replaced as often as phones.

1. The legal floor is five years.¹⁷
2. The expected time in use is longer, about ten years, and the support period has to reflect it.¹⁷
3. So Fota sets a support period of ten years from the sale of each unit and states the end date to users, which the user information in Annex II requires.¹⁸
4. A security update shipped in year eight must then stay downloadable until at least year 18, because 10 years after issue is longer than the two years left in the support period.¹⁷

The reporting duty that is already live

Since 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in its product must notify it, and the same applies to a severe incident affecting the product's security.¹⁹ "Actively exploited" means there is reliable evidence that someone has exploited it without the system owner's permission.²

The old article said you report "to ENISA". The precise version: you submit through the EU's Single Reporting Platform to the national Computer Security Incident Response Team (CSIRT) designated as coordinator, and the notification is made available to ENISA, the EU cybersecurity agency, at the same time.¹⁹ For a manufacturer whose main establishment is in Ireland, that coordinator is the CSIRT within the NCSC.¹¹¹⁰ The Commission says that platform has been operational since 11 September 2026.²⁰

For an actively exploited vulnerability there are three steps.¹⁹

The diagram reads from the top. The first three deadlines run from the moment you become aware, not from when you finish investigating. The final report runs from the moment a fix exists. For a severe incident the shape is the same, except that the final report is due within one month of the 72 hour notification.¹⁹ Throughout, you also inform the affected users.¹⁹

Micro and small businesses keep the duty. What changes is that the regulation's administrative fines do not apply to them for missing the 24 hour early warning deadline.¹³ Every other part of the reporting duty still applies.

Worked example: the clock at Fota Heating

An example: at 9.40am on Tuesday 10 November 2026, Fota's on call engineer confirms that attackers are using a flaw in the thermostat's cloud API to switch heating on in customers' homes.

1. Awareness: 9.40am, Tuesday 10 November.
2. Early warning due by 9.40am, Wednesday 11 November (24 hours later).
3. Vulnerability notification due by 9.40am, Friday 13 November (72 hours after awareness).
4. The fix ships on Monday 16 November.
5. Final report due by Monday 30 November (14 days after the fix is available).
6. Fota emails affected customers with what to do, as soon as it knows what they can do.

None of this works if the first question at 9.40am is "who do we tell". The process has to exist before the incident does.

Classes of product and conformity assessment

Most products need only a self assessment by the manufacturer, which the Commission confirms.²¹ The old version of this article put a figure of around 90% on that. I could not find that figure in the regulation or on the Commission's pages, so I have removed it.

Some products face more. Annex III lists "important" products in two classes and Annex IV lists "critical" products, with technical descriptions set out in Implementing Regulation (EU) 2025/2392.²²²³

• Class I includes operating systems, browsers, password managers, VPNs, routers and modems, and smart home security products such as door locks and cameras.²²
• Class II includes hypervisors and container runtimes, firewalls and intrusion detection systems, and tamper resistant microprocessors.²²
• Critical products include hardware security boxes, smart meter gateways and smartcards.²²

The old article also listed industrial automation systems as important or critical. They are not in the final annexes, so that has gone too.

Class I products can use self assessment only where the manufacturer has applied harmonised standards or equivalent specifications. Class II and critical products need a notified body or a certification route.²⁴ Once a product passes, it carries the CE marking, affixed before it goes on the market, and the manufacturer keeps technical documentation that includes the SBOM, which a market surveillance authority can request.²⁵

The penalties

Fines are set by each member state within ceilings fixed by the regulation.²⁶ For breaching the essential requirements or the manufacturer obligations in Articles 13 and 14, the ceiling is:

$$F_{\max} = \max\left(15{,}000{,}000,\ 0.025 \times T\right)$$

Here $F_{\max}$ is the highest possible fine in euro, $15{,}000{,}000$ is the fixed ceiling of €15 million, $0.025$ is 2.5% written as a decimal, $T$ is the company's total worldwide annual turnover for the preceding financial year in euro, and $\max$ means "whichever is higher". Foundations: percentages

Lower tiers apply to other breaches: up to €10 million or 2%, and up to €5 million or 1% for giving incorrect or misleading information to authorities.²⁶ Authorities must take account of the size of the business, in particular for micro, small and medium sized businesses.²⁶ Market surveillance authorities can also require a non compliant product to be withdrawn from the market or recalled.²⁷

Worked example: the ceiling at two sizes of business

An example: the regulation sets its ceilings in euro, the currency an Irish business keeps its books in anyway, so the arithmetic is direct.

1. A mid sized manufacturer with a worldwide turnover of €40,000,000. 2.5% of that is $0.025 \times 40{,}000{,}000 = 1{,}000{,}000$, so €1 million. The higher of €15 million and €1 million is €15 million.
2. A large group with €800,000,000 turnover: $0.025 \times 800{,}000{,}000 = 20{,}000{,}000$. The higher of €15 million and €20 million is €20 million.

The ceiling only starts to rise with turnover once 2.5% of turnover passes €15 million, which happens at €600 million, because $15{,}000{,}000 \div 0.025 = 600{,}000{,}000$.

The horizontal axis is the company's worldwide annual turnover, and the vertical axis is the highest possible top tier fine, both in euro. The line is flat at €15 million until €600 million of turnover, then climbs. For almost every small or mid sized business, €15 million is the ceiling that matters. That is a maximum, not a tariff, but it is a number that ends businesses.

Where businesses trip up

Underestimating scope. It is not only gadgets. An installable app, a plugin sold to other businesses or a browser extension can be in scope.⁶

Ignoring the supply chain. The unmaintained gem or the forgotten npm package in your dependency tree is now your responsibility under the due diligence duty.¹⁴

No vulnerability process. No security contact, no way to receive reports, no triage. The CRA makes all of this mandatory.¹⁵¹⁶

No SBOM. If you do not know what is in your software, you cannot answer the next Log4Shell, the 2021 flaw in the widely used Log4j Java library, when it lands in a dependency you never knew you had.²⁸

"We're too small." Size changes the fines for a late early warning and how authorities weigh penalties.¹³²⁶ It does not switch the obligations off.

Confusing CRA with GDPR. They are different laws. The CRA does borrow data minimisation as one of its product requirements, but meeting one never proves the other.¹⁵

The practical security work behind compliance

CRA compliance is not just paperwork. It rests on real security practice, and on a Rails stack most of it is well supported by existing tools.

Threat modelling and risk assessment. Before you ship, assess the risks: the attack paths, the data the product handles, what happens if it is compromised. Article 13 requires this assessment to be documented and kept up to date.²⁹

Static analysis and dependency audits. For Rails, Brakeman scans the application code for security issues and bundler-audit checks your Gemfile.lock against known vulnerable gem versions.³⁰³¹ GitHub's Dependabot can raise pull requests when a dependency has a known vulnerability.³²

Dynamic testing. OWASP ZAP tests a running application the way an attacker would, and the OWASP Top 10 is a sensible list of what to look for first.³³³⁴ I use Kali Linux regularly to test the security posture of the systems I build and manage, running everything from network scanning with Nmap to web application testing with Burp Suite.³⁵

An SBOM from the lock file. CycloneDX is a widely used SBOM standard, and the cyclonedx-ruby gem generates a CycloneDX SBOM from a Ruby project.³⁶³⁷

Worked example: an SBOM and a security contact for a Rails app

An example: Fota's thermostat API is a Rails app. Two small pieces of work cover two Part II requirements.

First, an SBOM on every deploy, in a CI step:

gem install cyclonedx-ruby
cyclonedx-ruby -p . -f json -o sbom/fota-api.json
bundle-audit check --update

The first command installs the generator, the second writes a JSON SBOM of the app's gems into sbom/, and the third fails the build if a gem with a known vulnerability is in the lock file.³⁷³¹ The SBOM is archived with each release, so Fota can hand an authority the exact list for any version.

Second, a published contact for vulnerability reports. The security.txt standard puts it at a well known address on the website:³⁸

# https://fotaheating.example/.well-known/security.txt
Contact: mailto:security@fotaheating.example
Expires: 2027-10-31T00:00:00.000Z
Policy: https://fotaheating.example/security/disclosure-policy
Preferred-Languages: en

Contact and Expires are the two required fields, and Policy points to the coordinated disclosure policy the CRA asks for.³⁸¹⁵ The single point of contact still has to appear in the user information as well, and must offer more than an automated form.¹⁶¹⁸

What to do now

First, map your scope. List everything you supply, and for each item ask where it runs and what it needs to work. Use the three businesses example as the template.

Second, set up reporting today. This is the obligation already in force. Decide who is on call, who decides that a vulnerability is actively exploited, and who submits through the Single Reporting Platform.¹⁹²⁰ Read the NCSC's guidelines once, so the team knows what the Irish CSIRT expects at each stage.¹¹ Rehearse it once with an invented incident.

Third, generate an SBOM for every product. Include transitive dependencies, and flag anything unmaintained.

Fourth, write the vulnerability handling process. A disclosure policy, a security contact, a triage routine and an update channel.¹⁵

Fifth, decide the support period. Five years is the floor, the expected time in use is the real answer.¹⁷

Sixth, build security into the pipeline. Static analysis and dependency audits on every commit, so a vulnerable gem fails the build before it ships.

Seventh, start the technical documentation. Risk assessment, architecture, SBOM, update policy. You need it for December 2027, and it is far easier written as you go.

Where I fit

I build Rails SaaS products and Solidus eCommerce stores, and security is part of the build, not a later add on. On my SaaS builds, each project faces a Kali Linux pass on staging before it faces the internet, endpoints are tested with Burp Suite and OWASP ZAP, Nmap and SQLmap check what is reachable and whether the database can be injected, and Brakeman and bundler-audit run in CI on every commit, so a vulnerable gem fails the build.

For CRA work, I set up CycloneDX SBOM generation so every deployment produces a current SBOM. All my production systems run on Linux, as I discussed in my piece on European digital independence, and I harden them according to the CIS Benchmarks: firewall configuration, SSH hardening, regular patching, minimal attack surfaces and ongoing monitoring.³⁹ For Rails and Solidus deployments that means Nginx or Caddy with proper TLS configuration, Docker containers with minimal base images and automated security updates.

If your Solidus store sells connected products in Ireland or anywhere else in the EU, the supply chain duties above apply to the shop, and the data side still has to satisfy the GDPR, which I cover in building GDPR compliant AI features in your SaaS. Where the question is legal, such as your exact role as importer or distributor, the answer belongs to a solicitor. I bring the engineering that makes the answer true.

Footnotes

1. European Parliament and Council, Regulation (EU) 2024/2847 (Cyber Resilience Act), Article 71, its closing formula and the Official Journal reference OJ L, 2024/2847, 20.11.2024, EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

2. European Parliament and Council, Regulation (EU) 2024/2847, Article 2(1) and Article 3, points (1), (2) and (42), EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

3. European Parliament and Council, Regulation (EU) 2024/2847, Article 69(2) and (3), EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

4. European Parliament and Council, Regulation (EU) 2024/2847, recitals 11 and 12, EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

5. European Commission, Commission publishes new guidance to support timely Cyber Resilience Act implementation, 2026, https://digital-strategy.ec.europa.eu/en/library/commission-publishes-new-guidance-support-timely-cyber-resilience-act-implementation

6. European Commission, Commission guidance on the application of Regulation (EU) 2024/2847, C(2026) 5252 annex, section 2, paragraphs 18 to 21 and examples 3 to 6, 2026, https://ec.europa.eu/newsroom/dae/redirection/document/131456

7. European Parliament and Council, Regulation (EU) 2024/2847, Article 2(2) to (7), EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

8. European Parliament and Council, Regulation (EU) 2024/2847, Article 3, points (13), (16) and (17), and Articles 19 and 20, EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

9. European Parliament and Council, Regulation (EU) 2024/2847, Article 14(7) and Article 18, EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

10. National Cyber Security Centre, About the NCSC, NCSC, 2026, https://www.ncsc.gov.ie/about/

11. National Cyber Security Centre, Guidelines on reporting obligations under Article 14 of the Cyber Resilience Act (CRA), NCSC, 31 August 2026, https://www.ncsc.gov.ie/pdfs/National_CRA_Guidelines_v1.pdf

12. European Parliament and Council, Regulation (EU) 2024/2847, recitals 18 and 19, Article 3(14) and Article 24, EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

13. European Parliament and Council, Regulation (EU) 2024/2847, Article 64(10), EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

14. European Parliament and Council, Regulation (EU) 2024/2847, Article 13(5) and (6), EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

15. European Parliament and Council, Regulation (EU) 2024/2847, Annex I, Parts I and II, EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

16. European Parliament and Council, Regulation (EU) 2024/2847, Article 13(17), EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

17. European Parliament and Council, Regulation (EU) 2024/2847, Article 13(8) and (9), EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

18. European Parliament and Council, Regulation (EU) 2024/2847, Annex II, points 2 and 7, EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

19. European Parliament and Council, Regulation (EU) 2024/2847, Article 14(1) to (8), EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

20. European Commission, Cyber Resilience Act reporting obligations, Shaping Europe's digital future, 2026, https://digital-strategy.ec.europa.eu/en/policies/cra-reporting

21. European Commission, Cyber Resilience Act conformity assessment, Shaping Europe's digital future, 2026, https://digital-strategy.ec.europa.eu/en/policies/cra-conformity-assessment

22. European Parliament and Council, Regulation (EU) 2024/2847, Articles 7 and 8, Annexes III and IV, EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

23. European Commission, Commission Implementing Regulation (EU) 2025/2392 of 28 November 2025 on the technical description of the categories of important and critical products with digital elements, EUR-Lex, 2025, https://eur-lex.europa.eu/eli/reg_impl/2025/2392/oj/eng

24. European Parliament and Council, Regulation (EU) 2024/2847, Article 32, EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

25. European Parliament and Council, Regulation (EU) 2024/2847, Article 30 and Annex VII, EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

26. European Parliament and Council, Regulation (EU) 2024/2847, Article 64(1) to (5), EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

27. European Parliament and Council, Regulation (EU) 2024/2847, Article 54(1), EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

28. NIST National Vulnerability Database, CVE-2021-44228 (Apache Log4j2), 2021, https://nvd.nist.gov/vuln/detail/CVE-2021-44228

29. European Parliament and Council, Regulation (EU) 2024/2847, Article 13(2) and (3), EUR-Lex, 2024, https://eur-lex.europa.eu/eli/reg/2024/2847/oj/eng

30. Brakeman, Brakeman: static analysis security scanner for Ruby on Rails, 2026, https://brakemanscanner.org/

31. RubyGems.org, bundler-audit, 2026, https://rubygems.org/gems/bundler-audit

32. GitHub, Dependabot documentation, GitHub Docs, 2026, https://docs.github.com/en/code-security/dependabot

33. ZAP, OWASP ZAP (Zed Attack Proxy), 2026, https://www.zaproxy.org/

34. OWASP Foundation, OWASP Top Ten, 2026, https://owasp.org/www-project-top-ten/

35. OffSec, Kali Linux, 2026, https://www.kali.org/

36. OWASP Foundation, CycloneDX specification overview, 2026, https://cyclonedx.org/specification/overview/

37. RubyGems.org, cyclonedx-ruby, 2026, https://rubygems.org/gems/cyclonedx-ruby

38. E. Foudil and Y. Shafranovich, RFC 9116: A File Format to Aid in Security Vulnerability Disclosure, RFC Editor, 2022, https://www.rfc-editor.org/rfc/rfc9116

39. Center for Internet Security, CIS Benchmarks, 2026, https://www.cisecurity.org/cis-benchmarks