Lifecycle

This section is based on the stage that are traditionally included in the software development life cycle. The ideas are to gradually introduce concepts in a way that can be used as reference along the way as your software development project moves along.

Determine what category the product falls into.

Make sure developers are adequately trained. Example OpenSSF - Developing Secure Software (LFD121) course.

Conduct initial risk assessment.

Manufactures must insure an appropriate level of security, taking well established security principles into account such as: secure by design, secure by default, minimize attack surface.

Regarding the data being processed and stored, the principle of data minimization must apply. Also, confidentiality, integrity and availability of the data must be protected.

Threat modeling should be performed as part of this stage. See threat modeling.

Developers should be familiar with and follow secure coding practices. Some resources are: OWASP Developer Guide, OWASP ASVS, NIST SSDF.

According to CRA, manufactures need to exercise due diligence when it comes to 3rd party components in software. Maintaining an inventory of vetted frameworks, libraries and algorithms can greatly assist in this regard.

Regularly running automated security testing tools can help catch issues early, without requiring significant manual work. Such tools include:

  • Software Component Analysis (SCA)
  • Static Application Security Testing (SAST)
  • Dynamic Application Security Testing (DAST)

A list of some tools/vendors can be found here and here.

Though such tools can help discover vulnerabilities, they also tend to report false positives. They also exhibit limited ability in discovering certain classes of vulnerabilities, such as flaws in program logic. It should be augmented with manual testing should be done, such as code review and penetration testing.

Verify that appropriate mitigations and security controls have been implemented base on the risk assessment.

Verify that each of the security requirements in Annex I have been met. Document how they have been met.

For physical products.

Ensure security of supply chain for hardware. Take reasonable actions to ensure that components have not been tampered with.

There are some procedures that need to take place when product is first put on market, or if significantly altered. Here is a quick overview, leaving out a lot of detail for brevity.

  • Conduct conformity assessment.
  • Draw up technical documentation.
  • Affix CE marking.
  • Draw up EU declaration of conformity.

See Annex VIII Conformity Assessment Procedures for details.

Technical documentation and EU declaration of conformity must be kept for at least 10 years or the support period, whichever is longer.

Whenever new software is released, including security patches and functionality updates. Also when first put to market.

Generate and store SBOM.

Ensure there is no known exploitable vulnerabilities, including 3rd party components. SBOM and SCA are vital to ensure this requirement is met.

Make sure the digital elements have not been altered in such a way, as to make the technical documentation invalid.

Ensure default configuration is secure. Example: can not ship with a hard-coded default password.

Scan SBOMs against databases of known vulnerabilities, such as CISA KEV, CVE, NVD, EUVD, VulDB, Snyk etc.

Provide OTA (over-the-air) updates (if applicable) with security fixes throughout the support period.

Monitor for new threats.

TODO

It can be an idea to look into methodologies or process models that incorporate security as an integral part of software development. Example: Microsoft SDL and NIST SSDF.