On June 24, a security researcher published a writeup of two Johnson & Johnson web apps he walked straight into. Both belonged to one of the largest medical device manufacturers in the world. Neither did the one thing its login screen implied it did.
The first was a campus recruiting site. The page sent you to a Microsoft sign-in, which made it look locked down to J&J employees. It wasn’t. The authentication library on the front end was the only thing checking who you were, and the actual data came from an API authenticated with a key hardcoded in the JavaScript anyone could read. Edit a few lines in your browser and the recruiter dashboard opened up — every student’s information, interview ratings, and notes. Nearly a thousand students exposed.
The second was worse. The Audit Tracking Management System is an internal app that runs audits across 20 J&J operating companies — LifeScan, Ethicon, DePuy, Biosense Webster, Abiomed, and more. Same pattern: the login redirected to Microsoft SSO, but the APIs behind it never actually checked the token. One unauthenticated call returned 13,600 employee records. The researcher found the system administrator’s name on a help page, looked it up in that employee list, spoofed a valid admin session, and had read access to confidential audit data across every company in the system. The fix took six months and a journalist’s email to J&J’s media relations to land.
I’m not writing this to dunk on J&J’s engineers. The opposite. J&J does roughly $90 billion in revenue, runs a coordinated vulnerability disclosure program, and — by this same researcher’s account of a 2024 report — has handled exactly this kind of thing extremely well before. If a company with that much security infrastructure ships a hardcoded API key and an API that forgets to check its own login token, the takeaway isn’t “J&J is careless.” It’s that writing secure software is genuinely, persistently hard — and it’s hard in a specific way worth understanding before you let a coding agent build the software your operation runs on.
The hard part doesn’t show up in the demo
Both of those apps worked. The recruiting site collected student information. The audit system tracked audits. If you sat through a demo of either one, you’d see a clean, functional product doing its job.
What you would not see — what no demo shows you — is whether the API actually verifies the login token, whether the secret key is sitting in plain text in code anyone can open, whether access control still holds when someone edits the page in their browser. Getting software to work is the visible 20%. The invisible 80% is authentication, access control, audit trails, error handling, secret management, data retention — the parts that only matter when something goes wrong, and stay invisible right up until they do.
That 80% is the entire job of the specialists J&J pays to catch a hardcoded API key. And one still went out the door.
Coding agents are good. That was never the question.
I run an AI company, so let me be clear about what I’m not saying. I’m not saying coding agents write bad code. They’re good and getting better. A modern agent will produce a charge-sheet intake form or an inventory tracker that works in the demo, and it’ll do it fast. The risk was never that the AI writes code that doesn’t run.
The risk is that the person directing it can’t evaluate the part that doesn’t run in the demo. If you’ve never shipped production software, you don’t know to ask whether the API checks the token — because in the demo it doesn’t matter. You’re logged in, it works, ship it. You find out it mattered when a researcher finds the gap, or when someone who doesn’t bother to publish a writeup finds it first.
J&J had people whose entire job is that question, and a hardcoded key still shipped. A commercial ops lead pairing with a coding agent has nobody in that seat at all.
In medtech, the invisible 80% is the regulated surface
This is where it stops being a general software lecture and becomes specific to you.
In operations software for a device company, the parts that don’t show up in the demo are the parts that carry the most risk. The charge-sheet tool handles lot numbers that drive recalls and patient information sitting a short hop from PHI. The order tool touches the pricing that drives revenue recognition. The consignment tracker is the system of record for where your field inventory physically sits.
Attackers and auditors go after the same things — access control, audit trails, data integrity — and those are exactly what a vibe-coded tool skips, because they never come up while you’re demoing the happy path. The same in-house tool that exposes you on the security side is also, under the QMSR transition, a GAMP Category 5 validated system on the regulatory side, carrying the heaviest documentation and lifecycle burden there is. That’s two different specialists’ jobs — security engineering and quality validation — bundled into a weekend prototype with neither.
Free Resource When Your Ops System Became a Validated System Why custom-built operations software now carries the highest-risk GAMP category, what QMSR pulled into audit scope, and the build-vs-buy framework for the call hiding inside every in-house tool. Read the guideShipping is the start of the obligation, not the end
One more detail from the J&J writeup is worth sitting with. The researcher reported both issues in October 2025. The recruiting site was fixed in three weeks. The audit system sat untouched through four follow-ups across six months and only got patched after a journalist emailed J&J’s media relations in April. This is a company that does disclosure well, having a bad stretch on a single ticket.
Keeping software secure isn’t something you finish. It’s a standing obligation — monitoring, patching, responding when someone reports a hole. Even J&J’s well-run process dropped one for half a year. A tool your ops team built over a weekend has nobody carrying that obligation at all. There’s no security team to report the gap to. There’s no one whose job is the patch. The person who wrote it with an agent has moved on to the next fire, and the code keeps running the order desk.
The question that actually matters
So for any operations tool — and this applies to ours as much as anything you’d build yourself — the question isn’t “does the demo work.” Demos are supposed to look easy; that’s what they’re for. The question is who owns the 80% you can’t see in the demo. For us that means security review, role-based access, and audit trails built into every release, not bolted on after a researcher or an inspector goes looking.
J&J has thousands of engineers and a real security program, and getting this right is still hard for them. Before you hand the system your cases run through to a coding agent and someone who’s never shipped production code, it’s worth being honest about what it would take to do better than the company that wrote the book on this — and what it costs you if you don’t.