What's new

This release catches the website changelog up with the latest content and maintenance work. We added new writing on dormant maintainer accounts in RubyGems and ViteVenom’s import-time malware pattern, both focused on practical incident-response questions rather than headline-driven fear.

Behind the scenes, dependencies were updated to pick up current fixes and keep the platform moving with the ecosystem. That kind of maintenance is intentionally boring, but it is part of building a security product that stays healthy over time.

The website changelog also now tells a clearer story again: from vulnerability rescans, to better transitive dependency guidance, to public security portals, to CI-ready SBOM uploads, to the latest supply-chain research.

We continued building out the boring.tools knowledge base with practical supply-chain security articles. Recent posts covered GitHub Action tag compromise, phantom squatting, npm 12’s safer install-script defaults, and the jscrambler package compromise.

These posts are not just marketing updates. They document the kinds of incidents boring.tools is being built around: malicious package versions, risky install-time execution, dependency confusion, and the need to understand which projects and environments were actually affected.

The product work and the writing are connected. The more clearly we explain real incidents, the easier it is to design boring.tools around the questions teams actually ask during response.

We added a dedicated landing page for GitHub Actions SBOM uploads, making it easier to understand how boring.tools fits into an existing CI pipeline. The page explains the workflow in product terms: generate an SBOM during the build, upload it to boring.tools, and keep vulnerability monitoring connected to the project that produced it.

Around the same time, staging deployments were adjusted to use mutable :staging application images. That is mostly an operational detail, but it matters because it lets us ship staging updates without turning every internal patch into a public image-tag story.

For users and evaluators, this release made the product easier to understand from the outside and easier for us to keep shipping behind the scenes.

This release made SBOM upload workflows much more practical for real teams. CI jobs can upload CycloneDX SBOMs directly to boring.tools, and project-scoped API keys keep those uploads limited to the projects they belong to.

We improved the upload API, preserved raw SBOM payloads from automation, added source metadata for CI uploads, and documented examples for GitHub Actions, GitLab CI, Forgejo Actions, and plain HTTP uploads. The frontend also gained setup snippets so teams can copy the right command for their project instead of piecing it together from API docs.

The result is a smoother path from “our build generated an SBOM” to “boring.tools is monitoring this project.” Teams can keep their existing CI systems and still get their dependency inventory into one place.

After the first portal release, we tightened the deployment path. The portal received its own container setup, staging configuration, runtime API URL handling, and a more polished branded landing page. Custom domain lookup was added so portal routing can work through customer-facing hostnames instead of only internal URLs.

We also connected backend services to error monitoring so production issues are easier to see and diagnose. The goal is simple: when something goes wrong, we should know quickly and have enough context to fix it without guessing.

This release made the portal feel less like a prototype and more like a deployable part of the platform.

This release introduced the first version of the boring.tools public security portal. Organizations can configure portal settings, publish vulnerability disclosure policy information, and receive vulnerability reports through a dedicated portal surface.

Inside the app, teams gained management views for VDP and VEX workflows. That means vulnerability disclosure, internal triage notes, assignees, and status tracking can live closer to the rest of the supply-chain and vulnerability data instead of being scattered across email threads or spreadsheets.

The portal work is an early step toward a more complete security operations flow: publish how researchers can contact you, receive reports in a structured way, and keep the response connected to the projects and artifacts you already track in boring.tools.

This release was mostly about making boring.tools easier to keep improving. Large frontend pages were split into smaller, focused components, route-only files were moved out of route directories, and data fetching was aligned more closely with the generated API client.

We also added an internal knowledge bundle that documents the product architecture, API routes, database tables, and code conventions. That does not show up as a flashy new button, but it makes future work safer and faster because the system has a clearer map of itself.

For users, the benefit is indirect but important: fewer fragile screens, fewer inconsistent API assumptions, and a codebase that can absorb new product work without becoming harder to change.

Not every vulnerable package is something you added directly. Often the affected package sits deeper in the dependency tree, pulled in by a tool, framework, or library your project actually depends on. This release makes that relationship easier to understand.

boring.tools now preserves more of the dependency graph during SBOM processing and uses it to show which direct dependency is responsible for a vulnerable transitive package. Instead of telling you only that a deep package is affected, the UI can point you toward the parent dependency that may need an update.

We also added better handling for cases where there is no clear parent fix available yet. That makes the vulnerability view more honest: sometimes there is a straightforward upgrade path, and sometimes the right next step is to monitor, suppress with context, or wait for an upstream fix.

This release focused on making the day-to-day experience more dependable. The vulnerability database sync now uses safer locking so only one OSV update runs at a time, reducing the chance of duplicate work or confusing scan states. When scans get stuck or fail partway through, the worker is better at finding stale jobs and retrying them automatically instead of leaving them for someone to clean up manually.

We also improved the staging environment with Grafana and cAdvisor monitoring. That gives us a clearer view of how the platform behaves while we ship changes, which helps catch deployment and runtime issues before they become product problems.

For users, the result is less visible friction: vulnerability data stays fresher, scans recover more predictably, and the platform is easier to operate while it keeps evolving.

boring.tools now rescans your projects automatically whenever new vulnerabilities are published to the OSV database, rather than waiting for the next scheduled sweep. As soon as a sync run adds or updates a CVE, boring.tools identifies which of your projects include a package in the affected ecosystem and queues them for an immediate rescan. This typically means you’re notified about newly disclosed vulnerabilities within minutes of them being published.

To keep things efficient, only the most recent SBOM per project is targeted, and only when it actually contains a package that matches the newly affected ecosystem and package name. Every rescan triggered this way is recorded in your audit log with a triggered_by: osv_update marker, so you have a clear history of what was scanned and why.

This closes the gap between a CVE being disclosed and your team finding out whether you’re affected.

boring.tools now notifies your team the moment a vulnerability scan finds new CVEs in your projects. You can connect multiple notification channels per organization—email, Slack, Discord, Microsoft Teams, or any custom webhook endpoint—and choose exactly which channels receive alerts. Webhooks support optional HMAC-SHA256 request signing so you can verify that notifications are genuine.

Alert emails include a severity breakdown table showing how many Critical, High, Medium, and Low vulnerabilities were detected, along with a direct link to the affected SBOM so you can get to the details in one click.

Setting up notifications takes a few seconds: go to your organization’s Notifications settings, add a channel, and use the built-in test button to confirm everything is working before your next scan runs. You can enable, disable, edit, test, or remove any channel at any time through the same settings page.

The CVE Database page now shows a sync status badge in the page header, telling you exactly when the local OSV mirror was last successfully synchronized and whether the most recent sync completed without errors. If a sync fails, you’ll see a clear error indicator rather than silently stale data. This transparency helps you understand the freshness of the vulnerability data you’re working with.

We’ve also unblocked API client code generation for teams consuming the boring.tools REST API. A pre-existing format issue in certain API path parameters was causing Orval validation to fail entirely, preventing any client code from being generated. This is now resolved so your generated API clients stay up to date.

We’ve published two new blog posts tackling current supply chain security topics.

The first covers Miasma, a self-spreading npm worm specifically designed to target AI-assisted coding tools. As AI code generation becomes more common in development workflows, understanding how malicious packages can exploit these tools is increasingly important for any team using AI pair programming.

The second post examines why VS Code’s decision to wait two hours before automatically applying extension updates is actually a sound security practice—and why your package manager should consider similar caution. The piece argues for a more deliberate approach to dependency updates as a practical defense against supply chain attacks.

We’ve published a new in-depth blog post on software supply chain attacks: what they are, how attackers exploit them, and concrete steps your team can take to defend against them. The post includes coverage of real-world incidents involving popular packages like axios and TanStack, providing context and lessons learned from actual breaches that affected thousands of projects.

If you’re responsible for dependency security in your organization or need to explain the risk landscape to stakeholders, this post gives you the background and language to make that case clearly.

boring.tools now has comprehensive public documentation covering all core features—getting started, projects, SBOM generation, vulnerability monitoring, and Git integration. Whether you’re onboarding new team members or need a quick reference, the docs give you everything in one place.

We’ve also launched a human-readable changelog on the website (you’re reading it), where each release is summarized in plain language rather than raw technical notes. Three new blog posts are live covering software supply chain security topics: a deep dive on SBOM fundamentals for developers, a guide to supply chain attacks and how to defend against them, and two posts about recent npm security incidents.

On the reliability side, Git integrations now automatically refresh expired OAuth tokens when they encounter a 401 response, which means your repository connections stay alive without manual intervention. We’ve also fixed an nginx configuration issue that was causing an unnecessary HTTP-to-HTTPS redirect hop on the /docs/ path.

We’ve made significant improvements to how boring.tools appears across the web. When you share links to our website on social media, you’ll now see rich previews with relevant images and descriptions instead of generic placeholders. Search engines like Google can now better understand the structure and content of our pages, which helps them index and rank our documentation and guides more accurately.

Behind the scenes, we’ve also strengthened the security of our website by adding protective headers that guard against common web vulnerabilities. We’ve cleaned up our redirects to work the way search engines expect, which preserves the authority we’ve built over time. Every page now has its own tailored description and proper headings, making it easier for both people and AI tools to understand what each page is about.

These changes make it simpler for your team to share boring.tools resources with colleagues and easier for search engines to help people find the documentation they need when researching dependency scanning and vulnerability management.

We’ve made it much easier to see what actually needs your attention. Vulnerability summaries and CVE details now automatically exclude vulnerabilities you’ve already patched, so your dashboard reflects only the risks that still matter. When checking which projects are affected by a vulnerability, boring.tools now looks at only your latest completed dependency scan per project, eliminating noise from older scans and giving you a clearer picture of your current security posture.

Working with Git repositories just got smoother too. The Git integration now includes a branch selector dropdown that lets you switch branches without leaving the page, making it faster to scan different parts of your codebase. We’ve also fixed an issue where branch selection wasn’t always being respected—now when you configure a specific branch for scanning, both manual scans and automated polling honor that choice instead of defaulting to your repository’s main branch.

Finally, we’ve polished a few rough edges: the organization chooser now displays a cleaner icon, and we’ve removed some debug logging that was cluttering your browser console.

We’ve fixed a frustrating issue where vulnerabilities would linger in your view even after you upgraded the affected dependency to a safe version. When boring.tools runs a new dependency scan and detects that you’ve patched a vulnerability, it now properly removes that issue from your vulnerability list instead of showing it as still active. This means your team can trust the vulnerability dashboard as a true reflection of actual security risks, without spending time investigating problems you’ve already solved.

This release includes minor dependency updates and internal maintenance improvements. No user-facing changes.

We’ve made GitHub integration more reliable and user-friendly. When your GitHub connection needs to be refreshed, the reconnect button now uses the standard OAuth flow so you’re always properly authenticated. You can also jump directly to your GitHub installation settings to manage which repositories are connected and what permissions are granted—no more hunting through GitHub’s interface. For teams with multiple GitHub organizations, we’ve added a helpful reminder that each organization needs its own separate connection to boring.tools.

Dependency scanning just got easier. You can now trigger scans across all your linked repositories at once, saving time when you need a complete picture of your codebase’s security posture. Behind the scenes, we’ve strengthened SBOM integrity by storing hash information and preventing accidental deletion of dependency files that are still in use. We’ve also added npm version recommendations in your scan results to help you stay current with best practices.

Finally, we’ve simplified authentication. boring.tools now uses magic links for login, removing the need to manage passwords while keeping your account secure.

We’ve built a comprehensive analytics foundation for boring.tools so you can understand how your team is using the platform and identify adoption patterns. The system combines frontend page view tracking with backend event tracking across authentication, dependency scans, vulnerability analysis, repository connections, and project management—giving you a complete picture of platform usage without compromising privacy.

Key actions are now tracked automatically: when team members sign up, log in, and out; when projects are created or switched; when dependency scans complete (including timing and vulnerability counts); and when repositories are connected or disconnected. This means you’ll soon be able to see valuable insights like which features drive the most engagement and where teams spend their security analysis efforts.

This release lays the groundwork for upcoming analytics dashboards and usage reports, helping organizations optimize their security workflows and demonstrate the value of dependency and vulnerability management to stakeholders.

We’ve made it easier to get support when you need it. The new integrated chat widget is now accessible right from your sidebar—just click the Support option and start chatting with our team. The chat loads instantly on demand, so it won’t slow down your experience, and you’ll automatically be recognized when you reach out.

We’ve also improved how search engines discover and index boring.tools. The website now includes a sitemap and robots.txt configuration, making it easier for developers to find us when searching for SBOM management and vulnerability tracking solutions. Plus, our blog now features cover images that give posts a more polished appearance and help them stand out when shared.

Finally, we’ve reorganized some of our documentation to be clearer and more helpful. Our popular Create React App guide now has a more descriptive URL, plus added quick reference cheat sheets and links to related content so you can find what you need faster.

We’ve completely overhauled how boring.tools displays breadcrumbs throughout the app. Whether you’re diving into a specific project, viewing a dependency scan, or investigating a vulnerability, you’ll now see a clear, accurate path showing exactly where you are. This means no more missing context or incomplete navigation trails—especially helpful when navigating deeply nested pages.

On the technical side, dependency scans are now smarter about versions. When you scan your project, boring.tools automatically detects your project version from manifest files like package.json, pyproject.toml, and Cargo.toml, so you don’t have to set it manually. This version is stored with your scan record and displayed in headers and breadcrumbs, making it easier to track which version of your project you’re analyzing.

We’ve also fixed several annoying UI bugs: breadcrumbs no longer disappear on nested pages, separators now render in the correct order, and you’ll no longer see React warnings in your console. These might seem small, but they make navigating boring.tools feel much smoother.

We’re excited to announce a major expansion of boring.tools with agent-based monitoring capabilities. You can now deploy lightweight agents that connect securely to boring.tools and stream live container metrics directly to your dashboard. Watch CPU, memory, network, and disk usage update in real-time as your containers run, giving you immediate visibility into the resource footprint of your dependencies.

The new agent system is built on secure, certificate-based registration, ensuring that only authorized agents can report data back to your workspace. Manage all your agents through the new agent management interface, see their connection status at a glance, and drill down into detailed metrics for any container. We’ve also redesigned the container table UI to make it easier to scan status and performance at a glance.

Finally, we’ve launched our beta signup program on the boring.tools website—if you’ve been waiting to try the platform, now’s a great time to join and help shape the future of the product.