This issue tracks the first OpenSSL detection rule after the C/C++ parser/language.
The support scope is agreed.
Proposed first rule
Start with one of the following, depending on the maintainer's preference:
EVP_DigestInit_ex with digest constructors such as EVP_sha256()
EVP_EncryptInit_ex with cipher constructors such as EVP_aes_128_gcm()
Expected output
The first rule should produce a CBOM cryptographic asset with source evidence,
similar to existing Java/Python/Go/C# detection paths.
Test fixture examples
The initial test should include one or two small C/C++ files containing direct
OpenSSL EVP usage. The fixture should intentionally stay small so failures are
easy to debug.
Acceptance criteria
- One OpenSSL EVP API family is detected.
- The detected value is translated into the existing mapper/enricher/output flow.
- Tests cover the fixture and expected finding.
- The PR does not introduce broader OpenSSL families in the same change.
Follow-up work
- Additional EVP ciphers and digests
- KDF APIs
- PKI APIs
- TLS protocol and cipher-suite APIs
- Broader library feasibility for wolfSSL, BoringSSL, libsodium, Botan, and Rust
This issue tracks the first OpenSSL detection rule after the C/C++ parser/language.
The support scope is agreed.
Proposed first rule
Start with one of the following, depending on the maintainer's preference:
EVP_DigestInit_exwith digest constructors such asEVP_sha256()EVP_EncryptInit_exwith cipher constructors such asEVP_aes_128_gcm()Expected output
The first rule should produce a CBOM cryptographic asset with source evidence,
similar to existing Java/Python/Go/C# detection paths.
Test fixture examples
The initial test should include one or two small C/C++ files containing direct
OpenSSL EVP usage. The fixture should intentionally stay small so failures are
easy to debug.
Acceptance criteria
Follow-up work