Adding new policies

[FotiosBistas]

Hello,

I was wondering whether it would be possible to support additional compliance policies based on external regulatory or certification frameworks. For example, the ECCG Agreed Cryptographic Mechanisms v2 published by ENISA defines approved, deprecated, and non-recommended cryptographic algorithms and parameter requirements:

https://certification.enisa.europa.eu/document/download/a845662b-aee0-484e-9191-890c4cfa7aaa_en?filename=ECCG%20Agreed%20Cryptographic%20Mechanisms%20version%202.pdf

Given that the EU Cyber Resilience Act (CRA) may rely on European cybersecurity certification schemes and associated guidance (such as ECCG) when defining cryptographic expectations, support for such compliance profiles could become increasingly relevant for vendors operating in the EU market.

[haritzsaiz]

In theory, there is an ext-compliance profile when implementing Docker containers, but the dependent container image ibm-regultator is not present (nor does it appear to have been uploaded to cbomkit ghcr). How can we invoke external compliance checks?

[san-zrl]

Hi @haritzsaiz, @FotiosBistas - I will have a look into this

[FotiosBistas]

Hi @san-zrl, just checking in on this — have you had a chance to look into it?

[san-zrl]

Hi @FotiosBistas, I'm trying to get approval to publish our regulator tool. I'll let you know when I have news on this.

[FotiosBistas]

Hey @san-zrl,

Sorry for the late reply. Thank you for the update, I appreciate you looking into this.

When you have the chance, would it be possible to share a general description of how this is expected to work?

More specifically, I wanted to understand whether the regulator tool would automatically perform compliance checks once a framework is provided. For example, could requirements from guidance such as the ENISA ECCG Agreed Cryptographic Mechanisms document be used directly by the tool to evaluate compliance? If not, could you clarify what would be needed from interested parties like us to implement that kind of policy checking? For example, would the rules need to be defined manually in some format or added through a separate integration?

And if there is anything we can do to help accelerate this effort, we would be glad to help.

Thanks again.

[san-zrl]

Hi @FotiosBistas , @haritzsaiz

1. ext-compliance in docker-compose.yaml is a leftover from an old version of the code. We have no intention to revive this. The mentioned regulator component will not be published.
2. There is an idea to connect CBOMkit directly with an Open Policy Agent (OPA) container. If configured this will be used instead of the built-in policy evaluation. OPA would evaluate an existing (previously stored) REGO rule over a CBOM sent by CBOMkit. Again, this is still an idea, there is not code yet.
3. This rule will be functionally equivalent to the built-in quantum-safe policy that is currently part of CBOMkit. For ECCG a corresponding REGO policy would have to be written. We do not intent do this ourselves.
4. The effort would be minimal with the goal to demonstrate the use of an external OPA instance. Of course, people are invited to extend this code base.
5. Since this is not the top-most priority there is no commitment or timeline. I cannot make any promises.

[FotiosBistas]

Hi @san-zrl, @haritzsaiz ,

I’m considering opening a pull request to prototype the OPA integration we discussed. I still have a few design and implementation questions, and I think it would be more useful to discuss them directly in the PR so everything stays documented and aligned with the code changes.

Would you be open to reviewing and providing feedback there when you have time?

[san-zrl]

Hi @FotiosBistas - Yes, please do.