Proposal: first reviewable slice for C/C++ and OpenSSL support in CBOMkit

[Rahulatram321]

Hi maintainers,

I would like to discuss a small, reviewable starting point for adding C/C++ and
OpenSSL support to the Sonar Cryptography Plugin.

I understand from recent PR feedback that GitHub PRs should be used for code
review, while broader work-stream planning should happen first in an issue. I am
opening this issue to align on scope before preparing any further implementation
PRs.

Motivation

CBOMkit currently supports Java, Python, Go, and C#, with C# still marked as in
development. A C/C++ path would help CBOMkit cover a large class of
security-sensitive systems where OpenSSL is used directly for cryptographic
operations.

OpenSSL support is especially useful because common APIs expose cryptographic
assets that map naturally into the existing CBOM pipeline:

• EVP digest APIs such as EVP_sha256() and EVP_DigestInit_ex
• EVP cipher APIs such as EVP_aes_128_gcm() and EVP_EncryptInit_ex
• KDF APIs such as HKDF, PBKDF2, and scrypt entry points
• PKI and TLS APIs that can expose certificates, key exchange, protocol versions,
  and cipher suites

Proposed first slice

Instead of trying to land full C/C++ support at once, I propose starting with one
small slice:

• Confirm the preferred C/C++ parser/analyzer integration approach.
• Add minimal language-support wiring only if the parser approach is accepted.
• Add one OpenSSL EVP digest or cipher detection rule.
• Add one or two C/C++ fixture files for tests.
• Translate the detected value into the existing mapper/enricher/output flow.
• Keep KDF, PKI, TLS, and additional OpenSSL families for later issues/PRs.

Why this scope

This keeps the first contribution reviewable and answers the riskiest question
early: whether the chosen C/C++ AST/parser API can provide the tree, symbol, rule,
and scan-context information needed by the engine interfaces.

The repository documentation identifies five interfaces that matter for adding a
language:

• IBaseMethodVisitor
• IDetectionEngine
• ILanguageSupport
• ILanguageTranslation
• IScanContext

The first slice should prove these can work for a C/C++ parser before expanding
the OpenSSL detection catalog.

Suggested implementation order

1. Parser feasibility notes and minimal type mapping for the engine generics.
2. Minimal C/C++ module skeleton and plugin registration.
3. One OpenSSL EVP rule with fixture-based tests.
4. Translation and enrichment for the detected EVP asset.
5. Follow-up rules for KDF, PKI, TLS, and other OpenSSL API families.

Questions for maintainers

• Do C/C++ and OpenSSL support a direction you want for this repository?
• Which parser/analyser approach would you prefer for C/C++?
• Would you prefer the first implementation PR to prove only parser/language
  wiring, or should it include one OpenSSL EVP detection rule?
• Are there constraints around C/C++ support that I should account for before
  writing code?

If this direction is useful, I can prepare the first PR around the smallest
maintainer-approved scope.