A package from a malware campaign may be stopped during installation or found later in a repository scan. Socket’s October 26 announcement puts those two kinds of evidence on the same campaign page. Teams using Socket Firewall and repository scanning can follow each status to a linked install event or scan report and check the package version and affected branch.
The change is in Socket Threat Intel’s Campaigns view. Socket says each campaign now gets an organization-specific, real-time summary labeled “Blocked by Socket,” “Detected in Firewall/SCA,” or “Not Detected.” These are Socket’s labels for what its products observed in that organization. A blocked install and a package found in source code call for different follow-up.
Where the campaign status comes from
Socket says the summary combines immutable full repository scans, immutable diff scans from pull requests, and Socket Firewall event traffic. The full scan can identify a package already present in a branch; the diff scan can catch one introduced by a proposed change. Firewall events supply the install-side record, including a block. The campaign summary brings these observations together, while the underlying report or event gives the team a specific place to investigate.
Open Threat Intel → Campaigns, choose the campaign, then open Org Impact. For each campaign package found in the organization, Socket lists the repository and branch, plus first- and last-seen dates. Those dates link to a scan report or matching Firewall events. For campaigns with several packages, the tab separates packages and versions, each with its own status and dates. Socket’s example identifies malicious versions of keyv and cacheable; use the version and linked record to scope each match.
Match each status to the right work
Start with the versions shown in Org Impact. For Blocked by Socket, open the linked Firewall event and identify the attempted install, its package version, time, and affected environment using the event’s actual fields. Then check whether that environment also has a matching package in a full or diff scan. A blocked attempt is evidence of a stop at that point, while a separate scan match deserves repository review.
For Detected in Firewall/SCA, follow the date link into the matching event or scan report. Use the listed repository and branch to find the dependency and the change that introduced it, remove the malicious version where present, and re-run the scan to check the new state. For a pull request, resolve the finding before merging; for an existing branch, trace deployments from that branch as part of the exposure review.
Not Detected is a Socket visibility result. Before treating it as an all-clear, compare your repository and package-install coverage with the places where that campaign’s dependencies could enter your environment. The announcement describes Socket full scans, PR diff scans, and Firewall events as its inputs. A team with unscanned repositories or installs outside the Firewall’s observed traffic should check those paths separately.
Finish with the linked evidence
Use the campaign page to prioritize the right repository, branch, package version, and install event. Follow each first- or last-seen date link to its scan report or Firewall event. After removing a detected version, verify the repository with a fresh scan. For a blocked install attempt, follow its Firewall event and check the environment for a separate scan match. Record the matched package version, affected repository or install event, what Socket blocked, and the change your team made.