boostsecurity.io

Pentesters have had Metasploit for decades. Attackers have had purpose-built offensive tools for CI/CD pipelines for a while now too. Until today, defenders didn't. SmokedMeat is the first open-source red team framework built specifically for CI/CD pipelines. Point it at your own infrastructure, run the full attack, see exactly what an attacker sees — credentials out of runner memory, cloud access exchanged, blast radius mapped. poutine finds the flaw. SmokedMeat shows what happens next. Check out the deep technical dive from Boost Labs below, or find SmokedMeat on GitHub. https://lnkd.in/guHjEE3h

Sébastien Graveline on our research team just published something worth reading if you use GitHub Actions for deployment testing...a novel attack technique that has never been documented before. The short version: an attacker opens a pull request from a fork, names a workflow environment anything they want, and GitHub automatically creates it. If your repo runs end-to-end tests on deployment events (which a lot of teams do, especially with Vercel, Checkly, or Argos CI), that workflow now executes in the context of your default branch with access to your secrets. The attack works even if you've patched the obvious injection. Because the attacker also controls the deployment URL, any workflow that sends your API key to a test server for authentication will send it to their server instead. Sébastien disclosed this to over 15 vendors starting in November. Argos CI fixed it. Checkly hasn't yet. The fix is less complicated than the attack. Full writeup and recommendations at the link. https://lnkd.in/e2mPNj3b

The FBI has warned about imminent extortion across thousands of organizations right now because a single misconfigured version tag in a security tool cascaded through five ecosystems in three weeks. TeamPCP harvested credentials out of runner memory, validated them with TruffleHog, and started doing AWS discovery before most victims knew they'd been hit. Our CEO Zaid Al Hamami has been talking about exactly this attack surface for years. Now that this type of exploitation has become a cascading, expensive reality, here's what he thinks is coming next ... and what security leaders need to understand before it does. https://lnkd.in/ehq8jC2x

Boost Security builds offensive and defensive tools to protect some of the world's largest companies from the exact attack paths exploited in the recent Trivy situation. Both of these tools are open-source and ready to use right now: Run bagel on your developer workstations to inventory the exposed secrets, tokens, and misconfigured AI tools sitting on your laptops. Choke off the credential supply before an attacker can move laterally. Run poutine on your CI/CD pipelines to locate the specific workflow vulnerabilities that allow command injection and privilege escalation in your build environment and close the loopholes that start this breach. We've got a response guide and forensic teardown of the attack below, and we're happy to help anyone who wants to understand more about how to guard against this (and similar) pipeline-based attacks. https://lnkd.in/d5Ujcr4x

The Boost Security Labs team has spent extensive time studying "Living Off The Pipeline" (LOTP) attacks, analyzing exactly how attackers can manipulate build tools and runner memory. On March 19, that research ceased to be theoretical. If you need a quick guide on how to check if you're impacted and protect yourself, we've got you covered. Relying on version numbers or standard SCA scans will leave you blind to this compromise. Because the attackers weaponized immutable tags, a SHA-level forensic audit of your action executions and an immediate secret rotation are required. We have published a technical analysis of this complex supply chain compromise over at Boost Labs. But we think what most people need right now is a tactical guide for rapid response, and you can find that right here: https://lnkd.in/d5Ujcr4x Stay safe, and we hope everyone had a great time at RSA!

Because Boost utilizes the Trivy vulnerability database, we have been asked how the recent incident affects our infrastructure and our customers. TL;DR: We're all good. The longer answer is that our architecture is built for data independence, which kept our platform entirely unaffected. A common misconception in AppSec is that ASPM = "scanner wrapper." In reality, Boost operates a multi-source ingestion engine. We sync data from over two dozen different ecosystems, then enrich this data with EPSS scores to determine true exploitability. The compromise at Aqua involved specific infrastructure (namely trivy-action and setup-trivy). Boost does not use these components. We maintain strict control over our own version upgrades and apply our internal scanning protocols to every artifact in our stack. Our ASPM is part of our overall AI-Native SDLC Defense Platform, and we treat vulnerability databases as one of many inputs. We combine that data with our own proprietary SAST rules and a policy-as-code engine. This separation of the "data layer" from the "execution layer" keeps our platform robust and resilient, stopping upstream infrastructure failures from compromising our customers' supply chains. Reliable SDLC defense requires independent architecture that doesn't depend on any single vendor's delivery mechanism. And that's exactly why we see so many organizations moving away from legacy setups in favor of Boost.

In 2022, we founded Boost Security with a mission: get security operating at the speed of development. We were tired of businesses seeing security as a cost sink and a bottleneck. We promised to build security that worked at developer speed. But over the last four years, the definition of "developer speed" completely changed. With AI agents in the mix, code is generated in milliseconds. The traditional speed limit of software engineering (which even *theoretically* would have topped out at max typing speed from your most productive engineer) has left the building. We believe engineering teams should use every tool available to ship faster, and security’s job is to make that velocity safe. But you can't protect an AI-augmented 2026 SDLC with 2022 manual triage queues. To keep our original promise of zero friction, defense has to operate on the exact same clock as your coding agents. That's why today, we are officially introducing the next evolution of Boost: Security at the Speed of Generation. We have rebuilt boostsecurity.io from the ground up to reflect how our mission has adapted to how software is actually built today. The Boost Security AI-Native SDLC Defense Platform is a single execution engine that secures the developer endpoint, blocks malicious supply chain ingestion, and auto-fixes code in real time...before the commit. Go ahead and floor the accelerator. We built the guardrails to handle the agentic era. At RSA and want to see it in person? Send a quick email to rajiv@boostsecurity.io and we'll make it happen! [Link to boostsecurity.io]

We started Boost Security with a pretty straightforward idea: security shouldn't slow developers down. That mission stayed the same. But what it means to "move at developer speed" has changed with incredible speed. Developers now use AI agents to write and refactor code in milliseconds. So if your security team is still relying on manual PR reviews and CI pipeline scans, you're either going to become a massive bottleneck, or you're going to get bypassed completely. Securing the new SDLC means a new way of "shifting left," focusing on an attack surface that has been left out of the conversation: the developer's laptop. That's why today, we're launching Boost Security Developer Endpoint Security. It secures the actual workspace where AI agents operate. It's your secret weapon for catching bad packages before they download and keeping secrets out of prompts. Security at developer speed now means security at the speed of generation. Check out the news below. (And keep an eye out next week! We’re launching a brand new website that brings this whole vision together.). https://lnkd.in/ec6tnxcC

welcome aboard Derek Summerville !

In late February, an automated “Pwn Request” campaign hit a set of high-profile open-source repos by probing GitHub Actions workflows at scale. Our team traced part of the activity back to a throwaway account (MegaGame10418) that appears to have rehearsed the same injection technique earlier against a publicly accessible New Relic test repository. Two takeaways stood out. First: attacker-controlled forks can hold the staging area for payloads, and that’s often where the most actionable early signal lives. Second: the underlying workflow weakness here is painfully ordinary: unsanitized pull-request metadata, over-scoped tokens, and permissions that turn a PR into an execution path. We've got the full analysis (timeline, payload details, and practical remediation steps) in our newest Boost Labs blog post. https://lnkd.in/eDU7m398