Skip to content

2026 ASPM Release Notes 🚀🚀

Boost Security ASPM release notes for 2026, newest release first.

2026-11-13

Fix with AI Through an LLM Gateway

  • Route the Boost Advisor's LLM Calls Through Your Own Gateway

    The Boost advisor that runs Fix with AI can now call the LLM through your own OpenAI-compatible gateway instead of calling the provider directly. The gateway can require OAuth2 client credentials, an API key sent in a header of your choice, or both. You set it up with a few BOOST_LLM_* secrets or variables in the pipeline that already runs the advisor, on GitHub, GitLab, Bitbucket, Azure DevOps and Harness, with no change in the dashboard. On GitHub and Azure DevOps, update the Run boost-advisor step from the template so it maps the new variables. Advisor pipelines that set none of the new variables keep calling the LLM provider directly with BOOST_LLM_KEY.

Manual Tags

  • Find Assets with No Manual Tag

    On Asset Management, the Manual Tags filter has a new No Tags option, next to Match any and Match all. It lists only the assets that carry no manual tag, so you can check that every asset is tagged, then select the untagged ones and tag them with Actions → Assign Manual Tags. Archived assets with no manual tag count as untagged. No Tags is available on Asset Management only. For direct API users, the AssetManagementFilter input of the asset inventory GraphQL API has a new withoutAssetTags field. Set it to true to get only the assets with no manual tag. It can't be combined with assetTagId or assetTagIds.

2026-10-30

SCA Reachability

  • Reachability Verdicts on Boost Security SCA Findings

    The Boost Security SCA scanner can now determine whether the vulnerable code of each CVE it reports is reached from your code. The verdict, Reachable, Unreachable or Unknown, appears in the Vulnerable Code Reached field of the finding details, and works with the existing Vulnerable Code Reached findings filter and policy action. Jira tickets created from a finding state Reachable: Yes or Reachable: No.

    Reachability analysis is opt-in: every Boost Security SCA scanner, new or existing, keeps scanning exactly as before until you turn it on with the Vulnerability Reachability Analysis setting of the provisioning wizard, or with BOOST_SCA_REACHABILITY=true in pipelines you maintain yourself. Once enabled, it runs on default branch scans only, never on pull requests, and adds roughly one second per CVE to the scan.

    Boost Security SCA now requires Boost CLI 1.0.193 or later, whether or not reachability analysis is enabled. Pipelines pinned to 1.0.192 or earlier must upgrade; pipelines on the major version channel (BOOST_CLI_VERSION=1) are already compatible.

Integrating with Code-To-Cloud Context Providers

  • Upwind Integration Available to All Accounts

    The Upwind integration is now available to every account, from the CSPM category of the Integrations page. Connect it with an Upwind API client to bring your Kubernetes clusters, the container images they run, and the services exposed to the public internet into Boost Security. See Integrating Upwind to Boost Security for the setup and what is discovered.

Bitbucket Integration

  • Connect Bitbucket With an Atlassian API Token

    The Bitbucket integration now connects with an Atlassian API token instead of a Bitbucket workspace app, so you no longer need development mode or development apps on your workspace. Create the token with Create API token with scopes for the Bitbucket app, then enter your Atlassian email and the token in the New Bitbucket Integration dialog. When the token expires, replace it with Update Personal Access Token.

    Zero Touch Provisioning for Bitbucket now runs through a three-step wizard. On its last step, you approve the BoostSecurity CI Provisioning Atlassian app, and nothing is installed from the Bitbucket Marketplace. See Zero Touch Provisioning for Bitbucket.

Boost Advisor on Azure DevOps

  • Service Principal Authentication Option for the Boost Advisor Pipeline

    The Boost advisor pipeline on Azure DevOps can now authenticate with a Microsoft Entra ID service principal as an alternative to a personal access token. A service principal isn't tied to a user account, and a single one works across every Azure DevOps organization connected to your tenant. You can reuse the app registration of your ADO Account Integration when it uses the App Registration method, or create one dedicated to the advisor. The updated boost-advisor.yml template supports both: it uses BOOST_SCM_TOKEN when that variable is defined in the boostsecurityio variable group, and otherwise requests an Azure DevOps access token on each run from AZURE_TENANT_ID, AZURE_CLIENT_ID and AZURE_CLIENT_SECRET. Existing personal access token setups keep working unchanged; to switch to a service principal, update your boost-advisor.yml from the template, add the three variables and delete BOOST_SCM_TOKEN.

    You can also keep the pipeline definition at any path of the boost repository by registering the pipeline yourself under the exact name boostsecurityio.boost-advisor.

Fix with AI on Harness

  • Fix with AI for Repositories Scanned by Harness

    Fix with AI now works for repositories scanned by the Harness Zero Touch Provisioning pipeline. Boost Security triggers a boostsecurity_advisor pipeline that you create once in your Harness project: the advisor runs on your own Harness compute and opens the fix pull request in the target repository, for every SCM the project scans (Azure DevOps, Bitbucket, GitHub and GitLab). See Enabling Boost advisor for the pipeline sample and the secrets and variable it needs.

Monorepository Management

  • Parent Repository Scans Exclude Sub-repository Paths

    The scans of a monorepo's parent repository and the scans of its sub-repositories are now mutually exclusive: the parent repository's scans skip the paths of its sub-repositories, which their own scanners cover. You can therefore provision the same scanners on the parent repository and on its sub-repositories without duplicate findings, and files added outside the declared sub-repositories, such as a new project directory not yet declared, are still scanned by the parent repository. Declaring a sub-repository removes its path from the parent repository's scans, so provision scanners on each new sub-repository.

Azure DevOps Integration

  • New Projects Discovered Within 15 Minutes

    Boost Security now checks your SCM integrations for new projects about every 15 minutes instead of once a day. A new Azure DevOps project, or a new GitLab group under a root integration, appears in Boost Security on its own within about 15 minutes, with webhooks installed and scanning on, and you no longer need to click Rediscover assets. Projects the integration can no longer see are removed on the next check. Discovery still finds only the projects the integration's credentials can read: in Azure DevOps, add the Boost Security service principal or the PAT's user to each new project.

Manual Tags

  • Match Any or Match All Manual Tags

    Manual tag filters now carry a Match any / Match all selector above the tag list, on every view that offers one. Match any is the default and shows the items carrying at least one selected tag. Match all narrows the results to the items carrying every selected tag, for example the assets tagged both critical and non-prod, and the applied filter in the Search For bar shows Match all before the selected tags. The page URL keeps the mode, so a shared link opens with it.

    On Asset Management and Scanner Coverage, several manual tags used to combine as if Match all were selected, unlike every other view. Both now default to Match any like the rest, so a saved or shared link to either view with several manual tags now shows the items carrying any of them. Select Match all to get the previous results. Saved views and shared links to the other views return the same results as before.

2026-09-30

Scanner Policies

  • Safe Deletion of Scanner Policies

    The Scanner Policies list now reports how many scanners each policy is assigned to, in a new Assigned Scanners column. While that count is above zero the Delete action is greyed out and names what has to happen first, instead of failing with an unclear error after the deletion is confirmed.

    The count links straight to the Scanner Coverage page filtered to that policy, so the scanners to deprovision are one click away. Scanner Coverage carries a matching Scanner Policy filter under More.

Jira Integration

  • Per-Project Auto-Close Settings

    Auto-close is now configured on each Jira project rather than once per connection. Every project carries its own Auto-close toggle and its own Closed status, chosen from the statuses that project actually defines in Jira, so a status from one project can no longer be applied to another. Each row is saved on its own, and picking an issue type is now staged behind that same Save instead of applying as soon as it is selected. The connection-wide auto-close toggle and its status dialog are gone.

    A project added from now on starts with auto-close Off and no closed status, instead of copying both from the account's default project. Turn it on for each new project you want it on. Existing projects keep the settings they have.

    Boost Security checks a status against the project's Jira workflow before saving it, and flags a stored status that Jira no longer offers so it can be corrected.

API

  • API Keys Are Scoped to Their Role

    An API key now has exactly the access its Role grants. An Endpoint key, such as a deployment token created from the Endpoint Protection Installation page, registers devices. A Data Upload key, which Boost Security creates and manages for integrations such as Zero Touch Provisioning, uploads scan, SBOM and telemetry results. Neither can read anything else in the platform. Previously every key also carried platform-wide read on top of the role it was given.

    Existing keys were migrated and keep behaving as they did, with one exception: a key whose only role was Data Upload or Endpoint has lost read access. If you were using an Endpoint or Data Upload key to query the GraphQL API, those queries now fail — create a User or Viewer key for the reads. See API Key Roles.

Policies

  • Policy Rules Can Match a Confidence That Is Not Set

    The Confidence attribute in the policy rule editor now offers Unset alongside High, Medium and Low, so a rule can target findings whose scanner never reported a confidence. Until now that value was not in the list and those findings could only be caught indirectly. See Matching a Confidence That Is Not Set.

    This changes what a rule can be written to say, not what any saved rule matches: a confidence that is not set has always ranked below Low, so a rule matching a confidence below Medium was already matching these findings. No policies were migrated.

Provision Scanners

  • Skip the Initial Scan When Provisioning

    The scanner-provisioning modal now offers a Skip initial scan after provisioning checkbox beside the Complete button, in both Easy and Advanced provisioning. Ticking it provisions the selected scanners without launching any scan jobs, so bringing a large set of repositories under coverage no longer floods your CI/CD pipelines. The initial scan still runs unless you tick the box, and the choice applies only to the provisioning you are performing.

    Skipping the scan leaves the affected security categories reporting as Pending until something scans the asset — including categories that are covered today, because a category reports as Pending as soon as any of its scanners is awaiting a first scan. Nothing is queued: the next push to the default branch, or a manual scan, clears it. See Skipping the Initial Scan.

Findings

  • Jira Tickets in the Findings CSV Export

    The Findings and Violations CSV exports now end with three columns describing the Jira ticket tracking a finding: ticket_key, ticket_url and ticket_status. A finding with no ticket exports three blank cells. See Jira Ticket Columns.

    The columns are appended after the existing ones, which keep their name, position and value, so an existing script that reads the export by header or by column index keeps working.

Azure DevOps Integration

  • Declared Organizations for Microsoft Entra ID and App Registration Integrations

    Azure DevOps integrations backed by Microsoft Entra ID or an App Registration now cover exactly the organizations you declare, instead of discovering them. Both installation wizards gain a step to declare the list before the webhooks are installed, and each organization is validated against the integration's credentials when you click Next: it must be readable and hold at least one visible project. Projects inside a declared organization are still discovered automatically, and personal access token integrations are unchanged.

    After installation, the list is edited from the Configuration tab of the integration's details, where a chevron on each Microsoft Entra ID or App Registration row opens the editor. Removing an organization detaches its projects while keeping their existing findings. Existing integrations were seeded with the organizations Boost Security already covered; review the seeded list once, since organizations that had already stopped being covered were not carried over. See Declared Organizations.

2026-08-19

API

  • API Key Expiration

    Application keys can now be given an expiration. The Add Application Key dialog offers an Expiration of 30 days, 60 days, 90 days or 1 year, and keys still default to never expiring. A new Expiration column in the Application Keys list shows when each key lapses.

    The expiration of an existing key — including a key created with no expiration — can be changed from the key's row at any time, and can be moved earlier or later. An expired key stops authenticating and stays in the list, marked EXPIRED, until an administrator deletes it.

2026-08-13

Posture Reports

  • Pending Scanner Coverage on the Coverage Chart

    The Coverage chart on the Report page now stacks a fourth state, Pending, next to Covered, Scan Error and Uncovered. It counts the assets whose provisioned scanners have not reported a scan result yet — the state a scanner sits in between being provisioned and completing its first scan. These assets were previously left out of the bars, so accounts that recently provisioned scanners will see taller bars than before, and the chart legend now names each of the four states.

  • Exact Counts on Report Charts

    Hovering over any chart on the Report page — Coverage, Violations, Findings, Critical Risks, and the per-finding-type Vulnerability and Coverage trends — now shows the exact counts behind the bar or point, instead of having to read them off the axis.

2026-08-03

Scanner Coverage

  • Scanner Policies

    Scanner Policies are named, reusable sets of directives that govern how the scanners they are assigned to behave. Define a policy once on the new Scanner Coverage → Scanner Policy page, then assign it to scanners across your assets.

    This first release ships one directive, File pattern matching, which restricts a scanner to the files it is meant to cover: the scanner runs only when the files changed by a pull request or pushed commit include a match for one of the policy's patterns; otherwise the scan is skipped and a passing check is posted to the SCM. Use it to keep an Infrastructure-as-Code scanner on Terraform and Kubernetes manifests, or an SCA scanner on dependency lock files. Further directives will extend what a Scanner Policy can govern.

2026-05-13

SCM Integrations

  • Bitbucket: API Token Authentication (Marketplace App Transition)

    Boost's Bitbucket integration now uses API Token-only authentication following Atlassian's deprecation of the marketplace app model. Users connect via Email and API Token and select their workspace from a dropdown within the integration card.

    • ZTP enablement automatically uses the configured token — no separate credential configuration is required.
    • Migration guidance: do not delete and recreate your existing Bitbucket integration before migration tooling and documentation are available. The recommended path will be communicated when ready.

AI-Powered Remediation & Governance

  • Fix with AI: Generally Available

    Fix with AI is now generally available to all users — no feature flag required. The Fix with AI button is visible and actionable on all supported findings. If pull request creation fails, a direct link to the pipeline logs is provided to assist with troubleshooting.

Policy

  • Parametrized Policy: Per-Asset Jira & Outbound Notification Configuration

    Teams can now configure Jira and outbound notification settings on a per-asset basis using External Configuration, accessible from the Asset Management page under Actions. When creating a policy rule action for notifications or tickets, users choose between Policy Designer (organization-wide settings) or External Configuration (asset-specific overrides).

2026-04-21

Scanners

  • SBOM: Lockless NuGet Package Detection

    Boost now supports SBOM scanning for .NET projects that do not use lock files, using the OSV Scalibr scanner. This extends software composition analysis coverage to NuGet dependencies that were previously undetectable without a lock file.

    Recommendation

    Enable only one SBOM scanner at a time. Concurrent scanners overwrite each other's results on each run; the UI does not currently prevent this configuration.

Integrating with Code-To-Cloud Context Providers

  • Upwind Integration: Runtime Reachability for Container Workloads

    Boost now integrates with Upwind to enrich findings with runtime reachability context. Teams can identify internet-facing vulnerabilities in container workloads and correlate images across multiple sources such as ECR and Google Artifact Registry. - Internet reachability context from Upwind can be used directly in policy rules to prioritize runtime-exposed risks.

AI-Powered Remediation & Governance

  • Fix with AI: Support for All SCM Platforms

    AI-powered fix generation is now supported across all four supported source code management platforms: GitHub, GitLab, Bitbucket, and Azure DevOps. Teams on any SCM can now receive AI-generated remediation pull requests directly in their repositories.

    Note

    Branch templates may require a manual update to activate this feature on existing integrations. Thorough documentation is provided for the setup process.

  • Fix with AI: False Positive Detection & Quality Review Agent

    Two new quality controls have been added to the AI remediation workflow.

    • False positive detection: the AI agent now evaluates whether a finding is likely a false positive before generating a fix. When a false positive is identified, it adds a noboost suppression comment rather than producing a code change.
    • Quality review agent: a second agent reviews the generated fix. If unsatisfied, it sends the fix back to the generation agent with feedback for up to three improvement rounds before failing open.

2026-03-30

AI-Powered Remediation & Governance

  • Fix with AI: Pull Request Integration

    The AI-powered fix workflow now surfaces status directly in the Finding Details panel. When a fix is submitted as a pull request, its PR status is visible inline — giving developers immediate feedback without leaving the Boost interface.

  • Fix with AI: Secret Validation & Rotation Guidance

    When the AI agent fixes a Secrets finding, Boost now validates the proposed change before applying it. A warning is automatically posted in the resulting pull request advising the developer to rotate or deactivate the affected secret, ensuring remediation is complete — not just code-level.

Integrating with Third-Party Notification Services

  • Jira Integration: Issue Type Selection

    Users can now configure the Jira issue type (e.g., Bug, Task, Story) directly from the Boost integration card, ensuring findings exported to Jira are created with the correct issue type for each team's workflow.

Asset Management

  • Export: Asset Type Column

    The Asset Management CSV export now includes a dedicated Asset Type column, providing additional context when reviewing exported asset data outside of the Boost platform.

Scanners

  • SCA: C# and JAR Package Support via OSV

    SCA scanning now includes support for C# (.NET) and JAR packages via the OSV scanner, extending open-source vulnerability detection to a wider range of ecosystems.

2026-03-11

Integrating with Third-Party Scanners

  • Dynamic Application Security Testing (DAST) with StackHawk

    Boost now supports DAST through a new StackHawk integration, enabling teams to detect runtime vulnerabilities in web applications alongside existing static and supply chain risk coverage.

    • New StackHawk integration card is available on the Integrations page. Activation requires a StackHawk API Key and a manually configured webhook in StackHawk.
    • New applications added in StackHawk are automatically synchronized on the next scheduled sync cycle.
    • DAST scanning can be enabled via Zero Touch Provisioning (ZTP), and results surface under a dedicated Policy scanner category.
    • Note: This feature is currently available under a feature flag.

Asset Management

  • Application-Level Grouping

    The Asset Management page introduces a new Application grouping view that organizes assets by application name. Each application can contain multiple environments, providing a cleaner structure for teams managing multi-environment deployments.

Integrating with Third-Party Notification Services

  • Multiple Jira Account Support

    Boost now supports adding multiple Jira integrations to a single account. Teams can mix Personal Access Token (PAT) and marketplace-authenticated connections and configure more than two integrations when needed.

    • Ticket IDs are surfaced on the Findings page. Note: IDs may appear identical across different Jira projects, but each links to the correct issue URL in the backend.

Account settings

  • Custom Pull Request Message Length Increase

    The character limit for custom PR messages has been increased from 200 to 1,000 characters, giving security and platform teams more room to communicate policy context and remediation guidance to developers in pull request comments.

2026-02-19

Software Supply Chain & Policy Refinements

  • This release sharpens the policy engine, expands SBOM filtering, and introduces early access to developer endpoint visibility to manage risk across every layer of the supply chain.

    • Low Maturity Package Cooldown Policy

      To guard against "brandjacking" and zero-day malicious packages, Boost now flags dependencies less than 7 days old as low maturity. This allows teams to create a configurable gate against rushing unvetted, brand-new code into production.

    • Advanced SBOM Package Version Filtering

      Users can now filter SBOMs by ecosystem, package name, and specific version ranges (supporting semver). This makes it significantly faster to identify if specific vulnerable versions exist anywhere in the environment.

Cloud & Integration Enhancements

  • AWS Bedrock: Improved Configuration Experience

    The Bedrock setup process has been streamlined with a new dialog featuring required permissions details, region selection dropdowns, guided tooltips, and the ability to select specific inference profiles for applicable models.

  • Jira: Automated Contributor Attribution

    When exporting SAST or Secrets findings to Jira, Boost now automatically identifies and includes the developer who introduced the code as the contributor. This eliminates manual git history lookups during ticket assignment.

2026-01-29

Supply Chain Security & Malware Detection

  • Malware Reporting Banner

    Boost now features a high-visibility malware reporting banner. If a malicious package is identified in your environment, an immediate alert appears upon login, providing details on the incident and guidance on how to identify impacted assets.

Enterprise Policy Management

  • Policy Inheritance

    Maintain organizational consistency by defining "Base Policies" that other policies can build upon. Base rules execute first to create a global security floor, while child policies layer on specific configurations for scanners and components.

  • Policy Rule: Block When Fix Is Available

    A new policy action allows teams to specifically trigger blocks or alerts on open-source findings that have a known fix version available, prioritizing actionable remediation over unpatchable vulnerabilities.