My buyers and sellers were heterogenous, so I could not acquire one user and get both personas; I purchased supply which had publicly-measurable demand and resold it below cost (in line with my target CAC) to bring the demand on platform. Once I had aggregated enough demand and developed the demand-side marketing and trust, I brought in the suppliers directly.
To better understand your thinking here, can you illustrate for me a scenario with less liquid markets because firms like JS are less efficient at making them, and the knock-on effects?
Really cool to see this! Building a security scanner specifically for LLM apps feels like an important step given how quickly production AI workflows are proliferating.
What stood out to me in the blog is how the scanner isn’t just a general linting tool — it actually traces inputs and outputs through the code to understand how untrusted user data might flow into prompts, models, and then back into privileged operations. That focus on data flow and behavior rather than just surface diffs seems like a solid way to reduce both blind spots and noise in alerts.
I also appreciate the emphasis on concrete vulnerabilities and real CVEs (e.g., LLM code executing arbitrary commands or translating LLM output directly into database queries) — showing that these aren’t just hypothetical risk categories but things happening in the wild.
A couple of thoughts / questions from my side:
Balancing precision vs noise: The blog mentions tailoring what counts as a real finding so you don’t overwhelm engineers with false positives. It’d be interesting to hear more about how that balance was tuned in practice, especially on larger codebases.
Integration with existing pipelines: I saw the GitHub Action auto-reviews PRs, but how do teams handle this alongside other scanners (SAST, dependency scanners, etc.) without ballooning CI times?
Vulnerability taxonomy: Prompt injection, jailbreak risk, and sensitive information leaks are all big categories, but there are other vectors (RAG-specific issues, tool misuse in agents). Curious how far the scanner’s heuristics go vs where red-teaming still wins.
Overall, a much-needed tool as LLMs go from experiment to core business logic. Would love to hear from others about how they’ve integrated this kind of scanning or what other categories of LLM security risk they’re watching for.
- On precision vs. noise: yeah, this is a core challenge. Quick answer is the scanner tries to be conservative and lean towards not flagging borderline issues. There's a custom guidance field in the config that lets users adjust sensitivity and severity based on domain/preferences.
- CI times: on a medium-sized PR (say 10k lines) in a fairly large codebase (say a few hundred K lines), it will generally run in 5-15 minutes, and run in parallel with other CI actions. In our case, we have other actions that already take this long, so it doesn't increase total CI time at all.
- Vulnerability types: the post goes into this a bit, but I would look at scanning and red teaming as working together for defense in depth. RAG and tool misuse vulnerabilities are definitely things the scanner can catch. Red teaming is better for vulnerabilities that might not be visible in the code and/or require complex setup state or back and forth to successfully attack.
Stylistically, this smells like it was copy and pasted from straight out Deep Research. Substantively, I could use additional emphasis on the mismatch between expectations and reality with regards to telco debt-repayment schedule.
