Getting Selected for the LFX Mentorship, and What I've Learned So Far About OpenSSL

I still remember checking my email that morning and seeing the subject line something like "Congratulations LFX Mentorship." I read it twice before it actually landed. Out of everyone who applied I got in, to work on CBOMKit, a project I'd only vaguely understood a few weeks earlier when I first read about post-quantum cryptography and thought wait, all of our current encryption is going to be broken someday?

Also a huge thanks to Aditya Koranga (my mentor) for choosing me. That was genuinely one of the best days I've had this year. Not because mentorships themselves are rare - if you look around, there's plenty. It felt good because this one was specific. I'd been reading about PQC on my own out of pure curiosity, not because a class told me to, and suddenly I had a mentor, a real codebase, and a real problem sitting in front of me instead of just articles.

This post is about what that problem actually is, what I've picked up so far, and honestly what I still don't fully understand. There's a lot.

What I Thought OpenSSL Was and What It Actually Is

Going into this, I genuinely thought OpenSSL was one thing - like one library, one job. Turns out it's four separate pieces that just happen to travel together:

• libcrypto - does the actual math (hashing, digital signatures, ciphers)
• libssl - built on top of libcrypto to run the actual TLS and DTLS handshakes (this is the part that lets something like Zoom encrypt a live call)
• A command line tool
• The EVP API - which I now understand is the modern interface most serious codebases should be using, partly because it was built with post-quantum support in mind

I didn't know any of this three weeks ago.

There's also BoringSSL, which I'd heard of but never really understood. It exists because of Heartbleed back in 2014 - a vulnerability that showed just how much of the internet was quietly resting on one under-resourced codebase. Google forked OpenSSL after that so they could keep a leaner, more aggressively updated set of primitives and just drop support for the old, less secure stuff that OpenSSL still has to carry around for backward compatibility. Chrome runs on BoringSSL now. So does Bun, apparently, even though Google originally meant it to stay internal. And Node.js, for what it's worth, still wraps OpenSSL directly - the most recent releases actually do support post-quantum algorithms natively through OpenSSL 3.5 and up. I only found that out because someone asked during a call and I had to go check.

Where This Actually Shows Up

The thing that made this click for me wasn't the theory - it was seeing where OpenSSL quietly sits inside stuff I already use:

• Nginx uses it for TLS termination and for handling Server Name Indication (SNI), which is the thing that lets one server host certificates for a bunch of different websites
• PostgreSQL uses it to encrypt traffic between the database and whatever's talking to it, and there's an extension called pgcrypto that uses OpenSSL directly for encryption inside the database itself
• JWT libraries lean on OpenSSL for HMAC signing and verification

None of this was surprising once I saw it. It was just never something I'd thought about before. It's the kind of thing you use every day and never once wonder what's actually happening underneath.

The Part That Took Me a While to Actually Appreciate

Here's the thing I didn't get at first. Java's crypto APIs are clean. You call Cipher.getInstance("AES") and that's basically the whole story - one call, one clear answer. OpenSSL is nothing like that. The same operation can be spread across a struct here, a macro there, and an initialization call three lines down - sometimes in a completely different function.

The first time this actually hit me was hearing that our detection module might miss a chunk of real usage simply because the information isn't sitting in one obvious place. And turns out that's not a hypothetical - it's a real, currently open question. Nobody on the team can tell you right now exactly how much of OpenSSL's API surface we actually cover. That used to bother me a little when I first heard it. Now it's basically become my job for the next two weeks, and honestly I like that better.

There's also a more boring practical problem underneath all this. OpenSSL 3.6 restructured its own header files in a way that broke naive path resolution, so the C/C++ side of things was literally failing to find headers it needed. That's being fixed by redirecting to the system's OpenSSL headers, which sounds simple written out like that but took real debugging to land on.

Where Things Stand Right Now

• C/C++ support is integrated into sonar-cryptography
• There's an OpenSSL detection module already, and it has what we're calling "meaningful coverage" - meaning it clearly works for the rules that exist
• What it doesn't have yet is confirmed full coverage of everything OpenSSL exposes
• Unit tests exist too, but again only for the rules that have actually been written so far - so test coverage is really just tracking rule coverage right now, nothing more

We're also deliberately not supporting older OpenSSL API versions at the moment. That's a real decision, not something that got missed. Keeping the scope tight matters more right now than trying to cover everything at once.

My Actual Job Right Now

My first task sounds almost embarrassingly simple when you say it out loud: find real open source C/C++ projects that use OpenSSL and actually test our plugin against them.

It sounds easy until you realize the point isn't just running a scanner and glancing at whatever comes out. Nginx, PostgreSQL, curl, OpenSSH, HAProxy, Apache httpd, Redis, OpenVPN, Postfix - these are all candidates, and the goal isn't to grab five projects that all do the exact same TLS handshake pattern. It's to find ones that stretch different corners of the API - X.509 parsing here, HMAC there, EVP ciphers somewhere else, DTLS in another.

For each one, I need to note:

• What it actually uses (legacy API or EVP)
• Roughly how big it is
• Why it's actually a useful test rather than just a familiar name

Small practical thing I already learned the hard way: clone with a single branch instead of mirroring the whole repo. Someone mirrored OpenSSL's own repository earlier in this project, and it took over thirty minutes just to clone. A single branch - ideally shallow too - avoids that entirely.

Once I have that list, the actual work starts. Run the plugin against each project, then go through the codebase myself and grep for the real OpenSSL calls - EVP_*, SSL_CTX_*, RSA_*, HMAC_* - and compare that by hand against what the tool actually reported. Where it agrees, fine. Where it doesn't, that's a gap, and I need to be the one who notices it - not assume someone already checked.

I'm planning to track all of this in a simple table:

It's slow, unglamorous work. But it's also the first point in this whole project where "coverage" stops being a vague, comfortable word and turns into an actual number.

After that, once the OpenSSL detection PR is merged on Shubham's side, I move on to wiring things into cbomkit-lib properly - making sure it pulls in the updated C/C++ module, resolves the right parser as a dependency, and can actually feed C/C++ source files through the fake in-memory server setup it uses (which, from what I understand, is genuinely more involved for C/C++ than it was for Java or Python, since C/C++ needs extra build context like compile commands and include paths just to be parsed correctly at all).

Alongside all of that, I'm also setting up a full SonarQube deployment through Docker, installing the plugin properly, and running it against one of the same cataloged projects - Nginx or curl, most likely. That's a genuinely separate path from cbomkit-lib, even though they share the same detection engine underneath, so both need to actually be checked on their own rather than assumed to behave the same way.

What I Don't Know Yet

I don't know yet how many gaps we'll find once I actually start running this against real projects next week. Could be a handful. Could be a lot. My honest guess, based on how scattered OpenSSL's configuration patterns are, is that it's more than we'd like.

There's also a longer-term goal sitting in the back of my mind now. My mentor sent me a paper recently - BF-CBOM from a group at the University of Bern - that basically ran multiple CBOM generators against the same codebases and found they barely agreed with each other at all. Almost no overlap. It's a slightly uncomfortable finding if you're building one of these tools, but it's also exactly the kind of honest, specific result we'd like to eventually be able to contribute ourselves. There aren't many papers out there yet on CBOM tooling specifically, and that feels like an actual gap worth trying to fill by the end of this mentorship - not just a nice idea to mention.

For now, though, my job is smaller and more concrete than any of that. Find the projects. Run the tests. Write down what's actually true - not what we assumed was true. I'll write about it either way.