An arrest changes the threat actor, not the installed artifact
The reported TeamPCP arrests are meaningful disruption. Closing an exposure still requires evidence about the code, credentials and publishing paths left behind.
ReversingLabs reported on August 28 that Australian authorities had arrested two men alleged to be connected with TeamPCP. Its account of the arrests also explains why software-supply-chain remediation remains a separate job: malicious artifacts and exposed credentials do not disappear when an alleged operator enters custody.
The arrests are allegations and an enforcement milestone, not a conviction. Nor do they prove that every affected package or credential remains active. Their practical significance is that one part of the threat has changed while the state of each exposed environment still needs checking.
I would keep two separate statuses in an incident review: disruption of the adversary and closure of our exposure.
Both matter. Treating law enforcement as irrelevant would be as mistaken as treating an arrest announcement as a clean bill of health for a build system.
Match the intervention to the mechanism
The supply-chain mechanism described by ReversingLabs uses stolen development credentials to alter further packages and repositories. That creates a route by which a compromised environment can contribute to another exposure.
Stopping an operator can disrupt coordination, access and monetisation. Cleaning up a particular environment requires evidence about the paths available there. The effect of the arrest on those paths cannot simply be assumed.
For a hypothetical affected development team, I would begin with the artifacts it actually installed and the credentials available when they ran. That scope is more useful than importing a campaign-wide victim estimate into the local incident record.
Then I would connect each exposure to a completed action: an affected build environment rebuilt, a credential invalidated, an unauthorised release removed or a publishing path restricted. The record should explain how the team verified the action rather than merely note that someone requested it.
Rehearse the next clean release
The test I would add is a release rehearsal from a known-clean environment. Use the approved source and dependencies, the intended publishing identity and the current restrictions. Confirm that the legitimate release can proceed and that superseded credentials cannot authorise it.
That is a proposed exercise, not an assertion that I have tested the affected campaign. Its purpose is to establish whether the team can resume work without reintroducing the access that made propagation possible.
A package version’s removal from a public registry may be part of that response. It does not establish the state of cached copies or already-built images inside the organisation. Those copies need to be included where the exposure assessment says they matter.
I would also keep intelligence updates open after local remediation. An investigation can uncover additional affected versions or access paths. A closed action for one known issue should not prevent a new finding from reopening the relevant part of the review.
The distinction makes the executive update clearer. We can welcome a significant enforcement action and still report precisely what remains to be checked internally. Neither message undermines the other.
The useful end state is more demanding than a reassuring headline: the organisation can show which exposure it had, which paths it closed and why the next release is operating from a trustworthy environment.
Let an arrest improve the threat assessment; let verified remediation close the exposure.
