[n1ckl0sk0rtge]

This PR adds experimental security behavior annotations to CBOMs. It uses security:cryptography:* values from the draft CycloneDX behavior taxonomy, such as encryptsData, wrapsKey and validatesToken.

The idea is to describe application behavior alongside the crypto inventory using a shared vocabulary. The annotations come from crypto operations and authentication APIs detected in source code.

Behavior instances are stored as JSON in the cbomkit:behaviors metadata property, keeping the CBOM valid for CycloneDX 1.6. Each instance has a stable ID and references the application as its actor. Native blueprints and behavior graphs remain outside this PR.

It also adds SecureRandom and key-unwrapping detection. Creating a SecureRandom is enough to add a random-generation behavior.

Design spec

Validation: 409 tests, seven skipped; Spotless and Checkstyle pass.

[san-zrl]

Hi @n1ckl0sk0rtge,

The build fails due to a failing test RuleMemoizationEnforcementTest.everyStaticRulesMethodIsMemoized. The CI log is blurred with lots of log messages like

11:09:13.386 [main] INFO com.ibm.engine.language.java.JavaDetectionEngine -- Detected constructor definition has more then one argument to resolve. Redefine the rule to explicitly define the param to resolve

so it's hard to find. Is this still work in progress or is it ready merging?

[INFO] Results:
[INFO]
[ERROR] Failures:
[ERROR]   RuleMemoizationEnforcementTest.everyStaticRulesMethodIsMemoized:119 [detection-rule classes whose static rules() is not memoized — wrap the body with Memoize.of(...) so shared subtrees are built once (see #476)]
Expecting empty but was: ["com.ibm.plugin.rules.detection.auth.PrincipalAuthRules",
    "com.ibm.plugin.rules.detection.auth.JwtAuthRules",
    "com.ibm.plugin.rules.detection.auth.MtlsAuthRules",
    "com.ibm.plugin.rules.detection.auth.AuthDetectionRules",
    "com.ibm.plugin.rules.detection.auth.SamlAuthRules",
    "com.ibm.plugin.rules.detection.auth.ApiKeyAuthRules",
    "com.ibm.plugin.rules.detection.auth.OAuthAuthRules"]
[INFO]
[ERROR] Tests run: 165, Failures: 1, Errors: 0, Skipped: 7
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Reactor Summary for sonar-cryptography 2.0.0-SNAPSHOT:
[INFO]
[INFO] sonar-cryptography ................................. SUCCESS [  0.646 s]
[INFO] common ............................................. SUCCESS [  1.696 s]
[INFO] engine ............................................. SUCCESS [  5.281 s]
[INFO] mapper ............................................. SUCCESS [  6.105 s]
[INFO] output ............................................. SUCCESS [  1.609 s]
[INFO] enricher ........................................... SUCCESS [  0.999 s]
[INFO] rules .............................................. SUCCESS [  0.545 s]
[INFO] java ............................................... FAILURE [ 10.387 s]
[INFO] python ............................................. SKIPPED
[INFO] go ................................................. SKIPPED
[INFO] sonar-cryptography-plugin .......................... SKIPPED
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  27.490 s
[INFO] Finished at: 2026-07-20T11:09:14+02:00
[INFO] ------------------------------------------------------------------------

[n1ckl0sk0rtge]

SecureRandomGetInstance is registered at the top level so the scan can detect standalone PRNG usage, such as creating a SecureRandom and calling nextBytes, even when it is never passed to another detected crypto API.

A depending detection rule would only run when a parent crypto rule follows that argument. No other production rule currently references SecureRandomGetInstance, so registering it here makes these rules reachable during normal scans.

This intentionally expands detection: recognized SecureRandom construction/factory calls produce a PRNG component and contribute generatesRandomValue to the new behavior summary. Construction alone currently counts as evidence; the rule does not require a subsequent nextBytes call.