These are products BulletproofSoft is building — not services we sell today. Each exists because assessment work we currently do by hand should be repeatable, evidenced and re-runnable rather than a point-in-time report.
Every page below states plainly that the product is in development.
AI and Software Assurance
- Agentic Red-Team Laboratory — prompt injection, tool poisoning, excessive permissions, data exfiltration and unsafe chained actions.
- Secure Software Supply-Chain Control Plane — SBOMs, reachability analysis, signed provenance and prioritized remediation.
Access and Resilience
- Zero-Trust Remote Technician Gateway — ticket-linked approval, session recording and controlled file transfer.
- Ransomware Recovery and DR Validation Platform — isolated test restores, integrity checks, startup tests and measured RPO/RTO.
If one of these solves a problem you have now, tell us about it — early conversations shape what gets built first, and we will be straight about timelines.
Why We Are Building Anything at All
The problems these concepts address are ordinary and well documented: standing vendor access with no expiry, dependency alerts nobody triages, backups that have never actually been restored, and now AI agents with tool permissions nobody has enumerated. An assessment can establish where an organization stands on the day it is written. Keeping that picture true afterwards is a different job, and it is the one these designs are aimed at.
What In Development Means Here
None of them are available to buy today. There is no trial, no license, no price list and no committed release date, and we do not publish ship dates we cannot stand behind. What those pages describe is intended design and not shipped behavior. Some of it will change substantially and some may never ship at all. We publish the designs anyway because the reasoning is useful on its own. If you read the supply chain page and decide to fix your exception process this quarter using tools you already own, that is a good outcome, and we are not owed anything for it.
A conversation at this stage is a design conversation. You describe the environment and the constraint that makes existing tooling awkward, and we say whether that changes what gets built first. Nobody is committed to anything on either side, and no budget cycle should be planned around a product that does not exist yet.
How to Read the Capability Lists
Every bullet on those pages describes intended design. Read them the way you would read an architecture proposal from a colleague. If one capability matters to you specifically, the useful question is where that piece currently sits and what would have to be true for it to work in your environment. Sometimes the answer is that nothing exists for it yet, and you should expect to be told that.
What Exists Today Instead
What these concepts aim to automate is available today only as hands-on work. Repository inventory, SBOM generation and dependency triage sit inside DevSecOps. Cloud, Kubernetes and pipeline hardening sit under platform security. Remote access exposure and control network segmentation show up in OT and ICS security assessment. Recovery gaps surface during incident response and in the resilience design covered under secure software development. Adversarial work runs under penetration testing and security assessment. Turning any of it into evidence an assessor will accept is the substance of security compliance readiness. If the need is immediate, those are the pages worth reading.