csm-security

---
name: csm-security
description: 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.
---

# Cloudsmith Security

Read [../../references/cloudsmith-core.md](../../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):

  ```bash
  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:

```bash
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):

```bash
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.