Csm security

Skill cloudsmith-labs/claude-code-skills/skills/csm-security

Investigate security posture in Cloudsmith — vulnerabilities, quarantine, and audit logs. Use when the user wants to scan an org, repository, or package for CVEs/vulnerabilities, investigate a specific CVE, review or manage quarantined packages, see who changed or deleted something (audit log), review security events, or get a security summary before a release or promotion.From its SKILL.md

Install

npx -y skills add cloudsmith-labs/claude-code-skills --skill csm-security

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.2 KB, as published. Nobody here has run it

Cloudsmith Security

Read ../../references/cloudsmith-core.md first: verify cloudsmith-state is working (otherwise run the setup skill), and follow its destructive-operation rules.

Vulnerabilities

Single package (CLI >= 1.16; resolve names to slug_perm via the csm-packages skill):

cloudsmith vulnerabilities OWNER/REPO/SLUG_PERM -F json \
  [--severity CRITICAL] [--fixable] [--show-assessment]

Org- or repo-wide scans are REST-only: GET /v1/vulnerabilities/{owner}/ and GET /v1/vulnerabilities/{owner}/{repo}/ (paginated — page through before summarising).
Summarise grouped by severity (Critical, High, Medium, Low): package, version, CVE ID(s), one-line description, fixed-in version when available. Lead with Critical/High.
For a specific CVE, filter the scan results to that identifier; the full advisory for one package is at GET /v1/vulnerabilities/{owner}/{repo}/{package}/{identifier}/.
Recommend remediation: upgrade paths, quarantining affected versions, or an automated policy (hand off to the csm-policies skill for deny/vulnerability policies or EPM rules).

Quarantine

A quarantined package cannot be downloaded. Both directions are security-relevant — confirm before either:

cloudsmith quarantine add    OWNER/REPO/SLUG_PERM   # block downloads
cloudsmith quarantine remove OWNER/REPO/SLUG_PERM   # restore downloads

List currently quarantined packages via search: cloudsmith list packages OWNER/REPO -q 'status:quarantined' -F json (if the filter errors, check the current grammar in the search-syntax reference of the csm-packages skill).
Before releasing a package from quarantine, show its vulnerability summary and why it was quarantined (package details + decision logs if an EPM policy did it — see the csm-policies skill), and get explicit confirmation.

Audit logs (who did what)

Via REST (org-admin permissions required):

GET /v1/audit-log/{owner}/            # org-wide
GET /v1/audit-log/{owner}/{repo}/     # single repository

Both accept ?query= filters and pagination. Present a chronological table: timestamp, actor, event, target resource, source IP. Highlight deletions, policy changes, membership changes, and token creation/rotation. For "what happened to package X" investigations, filter to that package and present a timeline. An empty result or 403 usually means the authenticated user isn't an org admin — say so.

Pre-release / pre-promotion checks

For "is it safe to promote/release" requests, combine: vulnerability scan on the exact packages, quarantine status, and (if EPM is in use) a policy simulation via the csm-policies skill — then give a clear go/no-go summary with the blockers listed.