Every product we run is a door someone will eventually try. The applications we build and host hold real data behind real logins, and "we're careful" is not a security posture. Barb is the part of the studio whose whole job is to try the doors first, to break into our own software, on purpose and under authorisation, and hand back exactly how, how bad, and how to close it.
Barb is the security node of the swarm, alongside Scout, which watches who visits, and Apiary, which runs the fleet. Its name is the bee's sting: the sharp end, pointed at our own defences before anyone hostile finds them. It is a repeatable penetration-testing methodology, not a one-off scan: onboard an application, audit it from the inside with full source access, attempt authorised break-ins against a running copy, and deliver severity-rated findings with concrete fixes. The rule underneath it matches the rest of the studio: a finding only ships once a human has proven it's real.
Whitebox: the source and the running app at once
Most external testing is blackbox, poking the app from outside and guessing at what's behind it. Barb tests our own software, so it works whitebox: it reads the code and attacks the running instance, and only trusts a finding when both sides agree. A suspicious line in the source becomes a real vulnerability the moment the same request succeeds against a live staging copy. Code without a working exploit is a hypothesis; an exploit traced back to its line is a finding.
A methodology, run the same way every time
Ad-hoc security testing finds whatever the tester happened to think of that day. Barb runs the same five phases on every engagement, so nothing gets skipped because it was late on a Friday. Onboard the stack and map the attack surface; run static analysis across the whole codebase; recon the live endpoints, parameters and roles; attempt active exploitation against a staging copy; then write it up. Each phase feeds the next, and the whole thing can be triggered with a single instruction (onboard and audit), so the process is the product.
Severity you can act on, not a wall of alerts
A report that flags four hundred things is a report nobody reads. Every Barb finding carries a CVSS score and a plain severity band of Critical, High, Medium or Low, so the fix queue sorts itself. Criticals are the ones that get someone else's data or take the system over; lows are the ones worth knowing but not worth a late night. The score is not decoration: it decides what gets fixed today and what waits for the next release.
Manually verified, no scanner noise
Scanners are where Barb starts, not where it stops. Static analysis, secret scanning and dependency checks throw up dozens of candidates, most of them false alarms, patterns that look dangerous but can't actually be reached. Barb's job is the part scanners can't do: take every High and Critical candidate and prove it against the source and a running exploit, and drop the ones that don't hold up. What lands in the report is the residue that survived a person trying to knock it down.
Rules of engagement
Offensive tooling is only safe when it's fenced. Barb tests only what the studio owns or is contracted to test, with written authorisation and a defined scope agreed before a single request goes out. It runs against staging or local clones by default, never production unless that's explicitly signed off, and it stays non-destructive. That means no data deletion, no denial-of-service, no load attacks. Third-party dependencies like single sign-on and payment processors are ruled out of scope up front. The point is to find our weaknesses, not to become one.
Where it's heading
Today Barb produces a written report per engagement. The next step is turning that into an access-controlled report page: every report reachable only through a signed, expiring share link rather than a PDF emailed around, with the structured finding data driving both the page and, over time, a picture of which weaknesses recur across the fleet so we can fix a class of bug once instead of one instance at a time.
Barb exists because the honest version of "your data is safe with us" is having already tried to steal it ourselves. It is the security discipline behind everything else the studio runs, the same instinct as Scout and Apiary, pointed inward. If you want the software you depend on tested the way we test our own, the way we work is the place to start, and the rest of the hive's notes are worth a read.