Starbound
Starbound Lab Notes: Vuln to Fix, in the Open — Post 1

How We Demo: Vuln, Detection, Response, Fix

·Atlas / Starbound

Most security vendors show you slides. We would rather show you a working storefront with a real bug in it, and then walk you through how we find it, catch it, contain it, and close it out.

This post kicks off Starbound Lab Notes, a series where every entry follows one intentional vulnerability from discovery to fix. Here is how the lab is set up, what the four-step story looks like, and two live examples you can open today.

What Starbound does

Starbound LLC is a remote-first security firm based in the United States. We do two things:

  • Threat intelligence (TI): tracking what attackers are actively exploiting, mapping it to your environment, and turning it into briefings your team can act on.
  • Threat response (TR): web app penetration testing, compromise assessments, and incident response readiness, so issues get found and fixed before they turn into incidents.

Our team is hybrid. Human analysts work alongside software-intelligence agents, which are AI teammates that help with detection and triage. The agents watch signals, flag anomalies, and assemble evidence. The humans confirm impact, make the calls, and own the fix. You get speed from the agents and judgment from the people.

The Starbound Lab

Everything in this series happens in infrastructure we own and operate:

Disclosure: the vulnerabilities in these lanes are intentional. They are planted on Starbound-owned demo sites so we can show real behavior without touching production systems or customer data. Nothing in the lab belongs to anyone else.

The four-step story

Every demo, and every post in this series, follows the same arc.

1. Vuln

We start with a specific, intentional weakness in a lab storefront. We describe what it is, where it lives, and why it matters to a business, in plain terms. We do not publish weaponization steps; the goal is to understand the risk, not to hand out a playbook.

2. Detection

Next, we show how the issue surfaces. Software-intelligence agents flag the signal, whether that is an odd request pattern, an unexpected script, or a missing protection header. A human analyst then triages it: is it real, what is the impact, and how urgent is it?

3. Response

Once confirmed, we respond as we would on an engagement: scope the exposure, contain it, preserve evidence, and communicate clearly to both engineers and decision-makers. This is where incident response readiness shows up in practice.

4. Fix and write-up

Finally, we ship the remediation and document it. Each write-up covers the root cause, the fix, how we verified it, and what the same work looks like when we do it in your environment.

Day-1 live examples

Two lab findings are live today. Both are intentional, both run on Starbound-owned demos, and both are safe to open in a browser.

Juice: reflected cross-site scripting (High)

  • Live demo: Juice promo XSS
  • What you will see: a harmless browser alert labeled starbound-lab-xss.
  • Why it matters: the storefront reflects a URL parameter into the page without proper handling. On a real site, the same class of bug can let an attacker run script in a customer's session, which puts accounts, payments, and trust at risk.
  • What we cover in the walkthrough: how the issue was detected, how impact was confirmed, and the output-encoding and content-security fixes that close it.

Coffee: clickjacking (Medium)

  • Live demo: Coffee clickjack
  • What you will see: the Coffee storefront loaded inside a frame on another page.
  • Why it matters: if a site can be framed by anyone, an attacker can overlay it and trick users into clicking things they did not intend to. It is a quieter bug than XSS, but a common one.
  • What we cover in the walkthrough: how missing framing protections are spotted, and the header-level fix that prevents it.

Technical reports

Want the detail behind both findings? Our technical reports live at starboundsec.com/test-lab/.

Why we demo this way

  • It is concrete. You see real behavior on real pages, not a diagram.
  • It is honest. Every bug is ours, planted on purpose, and disclosed as such.
  • It maps to your work. The same four steps are how we run engagements, so a demo is an accurate preview of what working with us looks like.
  • It serves both audiences. Engineers get root cause and fix. Decision-makers get risk, impact, and how fast it was closed.

What is next in the series

Upcoming Lab Notes go deeper on individual findings: one full Juice finding end to end, then a closer look at the detection and triage handoff between our analysts and our software-intelligence agents.

Book a 15-minute walkthrough

Want to see the lab live, or talk through your own environment? Email [email protected] for a 15-minute walkthrough or scoping call. We can cover:

  • KEV compromise assessment: are you exposed to vulnerabilities attackers are actively exploiting?
  • Web app penetration testing: the same find-confirm-fix process you see in the lab, on your applications.
  • Threat intelligence briefings: what matters to your industry right now, and what to do about it.
  • IR readiness: making sure your team knows what to do when something does go wrong.

Vuln to fix, in the open. See you in the next Lab Note.

← All Lab Notes Technical reports: /test-lab/ →