StackHawk is an application security testing platform that performs dynamic security scanning to find vulnerabilities in web applications during development and CI/CD pipelines.
StackHawk added in-place Team ownership management for applications with broader visibility for Members and View Only users, shipped a wingman skill bundle for GitHub Copilot, added new team-availability API endpoints, and fixed a bug where the PUT team-application endpoint silently failed to save assignments.
what's the number?
Each feature carries 0–100 for how completely the vendor documented it — not how big or important the work is. A major capability described in eight words scores low, and that is the finding.
- depth0–40 what it does and how it works or what changed
- specificity0–30 names real surfaces — APIs, flags, formats, limits, numbers
- actionability0–30 enough to go use it — a named endpoint, flag, or config key tops this; a UI path is a starting point
Code and config rank first by construction: a documented endpoint, flag or config key scores at the top of specificity and actionability, so it sorts above a feature described only in prose. Under 60 the notes go thin — everything below the “thinner coverage” line is thinner documentation, not smaller work. Hover any meter for that feature's three sub-scores.
Introduces wingman, a StackHawk umbrella plugin for GitHub Copilot that bundles four skills — hawkscan, stackhawk-api, data-seed, and optimize — in one install, since Copilot has no plugin-dependency resolution mechanism. Adds a separate hawkscan-ci skill installable via copilot plugin install hawkscan-ci@stackhawk for CI-focused scanning. Plugins installed via copilot plugin install are stored in ~/.copilot/installed-plugins/ and available across all projects, with additional project-skill directories configurable via the chat.agentSkillsLocations setting; the same marketplace catalog now also serves Claude Code and Codex.
$ copilot plugin install wingman@stackhawk
copilot plugin install hawkscan-ci@stackhawk
PUT /api/v1/org/{orgId}/team/{teamId}/application previously returned a success response without actually saving the Team assignment. It now saves correctly, but any application-to-Team assignments made through that endpoint before the fix must be re-run to confirm they are actually in place.
Adds a Team ownership column to the Applications table letting users change a Team assignment in place; applications without a Team are marked Unassigned and can be assigned by selecting the label and searching for a Team. Adds a matching Team field in Application Settings > General (with Unassigned at the top) so clearing or changing ownership works the same way in both places, and moving an application between Teams no longer requires removing it from its current Team first. Members can now open Teams they belong to and View Only users can review every Team in the organization without manage permissions. Team management controls (Create a Team, Add Members, Add Applications, rename, Delete Team) are shown disabled rather than hidden for users without manage permissions. In the Create Application flow, users who cannot manage Teams but belong to at least one Team must now assign the new application to one of their Teams, and the Filter by Unassigned Applications checkbox now returns results for Members and View Only users.
Adds GET /api/v1/org/{orgId}/teams/available/applications and GET /api/v1/org/{orgId}/teams/available/users endpoints to the API.
- !
PUT /api/v1/org/{orgId}/team/{teamId}/applicationpreviously returned a success response without saving the Team assignment; it now saves correctly. Any application-to-Team assignments made through that endpoint must be re-run to confirm they are actually in place. - !The
PUT /api/v1/org/{orgId}/team/{teamId}/applicationendpoint previously returned a success response without saving the Team assignment; assignments made through this endpoint were silently dropped and must be re-submitted to take effect.