Skip to main content

Changelog

Release notes for every Vulkro version

Plain-language release notes for Vulkro for Salesforce and Vulkro Core, newest first. Read one product or both together.

Release artifacts on dist.vulkro.com ship with SHA256SUMS and a CycloneDX SBOM.

Both products: 49 releases, newest first.

UnreleasedCoreNo changes recorded yet
UnreleasedSalesforceNo changes recorded yet

Added

  • Entry points for every route, in JavaScript/TypeScript, Java, Python and Go. Each endpoint now names the function that handles it, its full path (with router, group, blueprint and mount prefixes applied) and the guards that protect it. Covered: Express, Fastify, Koa, Hono, NestJS (global prefixes, global guards and opt-out decorators), Next.js (route handlers, pages, server actions and middleware matchers), tRPC, GraphQL resolvers, Spring MVC and WebFlux, JAX-RS, Quarkus, Micronaut, servlets, Django and Django REST Framework, FastAPI, Flask, Starlette, aiohttp, gin, echo, fiber, chi, gorilla/mux, net/http, gRPC and connect-go. MCP server tools and LLM agent tools are entry points too, so a tool that passes its input to a shell, a query or a file is reported.
  • One severity model. Severity now comes from who can reach the code (anonymous, any signed-up user, an internal user, an administrator), what is at stake (code execution, file access, account takeover, other users' data, internal network reach), whether the path is proven, and whether a guard stands in the way. Every placed finding says why in its reason.
  • Authorization checks. One check decides whether a route is authenticated, whether a record is scoped to the caller and whether a role is required. New findings: lookups by id with no ownership check, role changes with no role check, Next.js server actions without authorization, middleware-only authentication, unguarded route groups, over-wide permitAll rules, unsigned webhooks and request bodies written straight to the database.
  • One issue per root cause. When several analysis passes report the same flaw, the scan shows it once and lists the other reports under it. A suppression or triage decision on any of them applies to the issue.
  • vulkro verify <results.sarif>. Checks another tool's SARIF findings against Vulkro's own proof and marks each one proven, not provable (with the reason) or not examined.
  • vulkro why-not <path[:line]>. Explains why nothing was reported at a location: not read, no entry point reaches it, a guard or sanitiser applies, suppressed, folded into another issue, or below the confidence floor.
  • Verified fixes. vulkro fix --verify applies each proposed patch to a copy of the project and scans it again, keeping only patches that remove the finding without adding a new one. --bundle writes the verified patches and --apply applies them. SQL fixes use the bound-parameter form of the driver you use. The MCP server gains verify_fix.
  • Risk category and origin on every finding. Each finding carries one of ten categories and where its file comes from (first-party, test, example, generated, vendored or browser code). Findings in test, example and vendored code are reported at Low at most, and server-side rules no longer fire on browser code.
  • Go dependency reachability per advisory. Each Go vulnerability is checked against the exact function the advisory names: reachable (with the call path), imported but not reached, or not imported.
  • Malicious package behaviour. Install scripts that fetch or run code, setup.py files with network or exec at import, executable .pth files, and packages resolved from the public registry under a private-looking name.
  • AI bill of materials. --format aibom lists LLM SDKs, model identifiers, model files and MCP servers with file and line evidence.
  • Compliance packs for the OWASP Top 10 for LLM Applications 2025, the OWASP Top 10 for Agentic Applications and the CERT-In SBOM guideline, plus vulkro sbom --check FILE --profile cert-in.
  • Exposure report. vulkro report exposure summarises one application's entry points by authentication state, unauthenticated reach to sensitive code, proven Critical and High findings and authorization verdicts, as HTML, Markdown or JSON.
  • Notifications to several destinations at once with --post-to, saved destinations, and Jira issues updated instead of duplicated on re-runs.
  • New sinks and sources across the four languages, including Java XXE, deserialization, Kryo, ScriptEngine and SpEL, MyBatis XML mappers and Spring Data queries, Thymeleaf view names, JavaScript prototype pollution, ReDoS and import-aware file and database sinks, Python HTTP client objects and Django .extra, and Go GORM, sqlx, http.ServeFile and text/template.

Changed

  • Editor and console triage share .vulkro/triage.toml. Marking a finding as a false positive or accepted risk in the editor or the console writes the same file the CLI reads.
  • Quieter editor. Diagnostics start with the proof tier in words, show the risk category and the proof hops on hover, hide the lower-confidence tier by default, and re-analyse only the saved file.
  • Go same-package calls and parameter-type call resolution are on by default, so more Go and TypeScript flows carry a full proof path.

Fixed

  • Scans no longer crash with a stack overflow on Go code where a function literal calls itself through its own variable.
  • Fewer false positives: a writer argument is no longer treated as written data (server-sent events, CSV and zip writers are not HTML), test and example keys are no longer High or Critical, sanitisers, allowlists, parse pipes and validate-then-reject checks are recognised, bound query arguments are not SQL text, and missing-authentication findings on public-by-design routes are no longer Critical.

Fixed

  • vulkro-sf cloud connect says when a connection is waiting for approval. On a workspace that requires an admin to approve new connections, the command now says the connection is on hold and where an admin approves it, instead of reporting success. A command refused because the connection is still pending, or because this network is not on the workspace's allowlist, now gives that reason instead of blaming your workspace role.
  • vulkro-sf logout revokes the device and frees it from your seat, so you can sign in on your next machine straight away. It previously signed out locally only and reported the server as unreachable.

See what the latest release finds in your code and your orgs.