What We Built This Summer at Boost

Our team shipped a lot between July and September.

We expanded the parts of the development environment that security teams can protect, gave teams more control over how Boost runs across large deployments, and made it easier for developers and security teams to understand what Boost sees and why it takes action.

Here are some of the biggest things we worked on this summer.

More coverage across the development environment

We spent much of the summer expanding what security teams can see and protect across developer endpoints, repositories, packages, and CI/CD.

For .NET teams, that now includes NuGet. Developers who use dotnet, nuget, Visual Studio, or VS Code can get package inventory and install-time protection for packages from the public NuGet registry. Security teams can see those packages alongside the rest of their endpoint inventory, and SafePackage can apply policy when developers install them.

We also made some major changes to SafePackage itself.

Developers use package managers in a lot of different places. They work inside Python virtual environments, WSL2, Go projects, local shells, IDEs, and different user accounts on the same machine. This summer, we moved SafePackage to a per-user daemon so developers get more consistent coverage across those environments.

We changed endpoint inventory so we process incremental changes between scans rather than processing the full inventory every time. We can now check endpoints more frequently while doing less work on each scan.

Security teams got broader coverage in ASPM and the software supply chain too. Boost Secret Detection can now detect Base64-encoded secrets and tell teams how Boost found them encoded. Teams can flag GitHub Actions that reference an action without pinning it to a full commit SHA. We also expanded our missing-lockfile rule across .NET, Haskell, Scala, Swift, Julia, R, C/C++, and Ruby.

Teams investigating package risk can now see Open Source Malware feed data on affected packages in both ASPM and Endpoint Protection.

Customers may never think about most of the plumbing behind these changes. Their developers should simply get protection across more of the tools and ecosystems they already use.

More control for the people running Boost

As customers deploy Boost across more repositories and developer machines, security teams need precise control over what runs and when.

Teams can now tell a scanner to run only when certain files change. If a scanner cares about poetry.lock, for example, engineers can change unrelated files without spending CI resources on a scan that has nothing new to inspect. Boost records the scan as skipped so security teams can still see what happened.

Teams can also skip the first scan when they provision repositories. An AppSec team rolling Boost out across a large repository set can provision everything first and let each repository run its first scan on the next push or during a manual scan. While teams wait for those first scans, Boost shows the assigned scanners as pending in coverage.

Admins now have less key management to do by hand. When a team deploys Endpoint Protection, each endpoint can automatically negotiate its own unique key through a short-lived key-granting process. Admins no longer have to create and distribute individual keys across the fleet, but they can still revoke a specific device from the Devices page if a machine is compromised or an employee leaves the company.

Admins can also set application keys to expire after 30 days, 60 days, 90 days, or one year. We tightened the permissions on Data Upload and Endpoint keys so those keys can push the data they need to send and fetch the policies they need to enforce.

Jira admins got finer control over automatic ticket closing as well. They can choose the appropriate close status for each Jira project connected to Boost, which makes the integration work much better for teams that manage several projects with different workflows.

Clearer answers for developers and security teams

We spent the summer making it easier for people to understand what Boost is doing too.

When SafePackage blocks a package, developers can now see why. Boost can tell them that a package matched a malware advisory, has low maturity, looks like a hallucinated package or typosquat, or has reached end of life. Developers get useful context at the moment they need to decide what to do next.

Security teams can get to the details faster. When someone clicks the scans or failed-scans tiles on the dashboard, Boost takes them to the corresponding filtered scan results. People looking at posture charts can hover to see the actual numbers behind findings, trends, and coverage.

Teams can see scanners that are still pending their first run directly in the coverage chart. That gives the person reviewing coverage a clear account of which scanners have completed work and which ones are still waiting.

For teams that work in spreadsheets or pull Boost data into other processes, findings and violations CSV exports now include the associated Jira ticket key, URL, and status. Analysts can keep the connection between a finding and the work happening in Jira when they take that data outside Boost.

A busy summer, with more to come

When we look back at what we shipped this summer, we see a lot of work aimed at the people who use Boost every day.

We helped security teams cover more developer tools, package ecosystems, repositories, and pipelines. We gave admins finer control over scanning, credentials, devices, and integrations. We gave developers clearer explanations when Boost steps into their workflow.

And we have plenty more underway.