Hey there HN! My name is James, and I'm the developer of Nabla. The journey building this was a massive learning experience and I'm still learning things about this market as I go, but I wanted to tell you a little bit about Nabla that I think excite me about the future and why I chose firmware as opposed to the normal cloud path for GRC. It actually went through a weird three step journey. What started off as a general BCA tool I wanted to build just to challenge myself because I saw Fossa advertise it on their website, turned into a weird snowball of trying out different things with binary composition analysis. I ended up realizing the our typed Rust struct which standardized the composition opened up the door to a lot of things I was wanting to do, and beginning to over-engineer before I dug in and looked at what was being extracted better. What we ended up with was a pretty nice CLI that can scan firmware of multiple types and produce machine readable compliance artifacts. The CLI uses: - goblin for parsing ELF, Mach-O, and PE formats - capstone for lightweight disassembly where needed - A custom BinaryAnalysis struct to normalize metadata - The BinaryAnalsis structured results are fed into an LLM, which maps findings to OSCAL controls Right now it covers 122+ controls, but the control set is expanding. The LLM isn’t a black box here — it’s grounded by the structured analysis, so it doesn’t just hallucinate. I’d love feedback on: - Usability, once I publish docs (install/run experience) - Accuracy of the OSCAL mappings - Ideas for handling edge cases (firmware blobs, weird file formats) Thanks, and happy to answer questions! |