--- title: "Where SAST stops and artifact management begins" description: "SAST and secret scanning protect first-party code, while dependencies enter by another route. See how artifact management checks packages before install scripts run." canonical_url: "https://cloudsmith.com/blog/where-sast-stops-and-artifact-management-begins" last_updated: "2026-11-12T13:00:00.000Z" --- # Where SAST stops and artifact management begins A team can pass every static analysis check, keep secrets out of its repositories, and still end up with attacker code running on a developer workstation. The team’s security process ran as expected and the malicious code never touched their repository. It arrived as a dependency, pulled in by `npm install`, and ran during installation, through an entry path their static application security testing (SAST) tool was never designed to watch. ## **SAST and secret scanning catch problems in the code you write** SAST reads first-party source code and flags patterns that can lead to vulnerabilities, like injection flaws, unsafe deserialization, memory misuse, and hardcoded credentials. It catches these before the code ships, when fixing these issues is easier to do than after a build or if that code reaches production. SAST runs where developers work. It can run as an IDE plugin, as a CLI on a workstation, and as a commit hook, pull request check, or CI gate. This flexibility makes it one of the few security controls a developer can see in their own workflow, displaying findings next to the line that raised the concern. Secret scanning often sits alongside SAST and catches leaked API keys, tokens, and passwords before they reach a shared repository. GitHub can [block a push that contains a known secret format](https://docs.github.com/en/code-security/how-tos/secure-your-secrets). A tool like [TruffleHog](https://github.com/trufflesecurity/trufflehog) goes a step further and checks whether a credential it finds still works. Semgrep, Snyk Code, GitHub CodeQL, Checkmarx, Veracode, and Aikido all cover SAST, and most of those platforms include secret scanning alongside GitHub’s native scanning and TruffleHog. These tools protect the code you write and the repositories that code lives in. ## **AI agents need the same review gates that humans do** In addition to human developers, AI coding assistants write first-party code that needs the same SAST checks and human review. The coding patterns that SAST tools look for come from studying how people write vulnerable code. AI assistants can produce code that falls outside of those habits, and can be pushed further outside those patterns. The authoring environment is also an attack surface in its own right. Attackers target tools that run with a developer’s privileges like IDE extensions, AI editors like Cursor, and Model Context Protocol (MCP) servers. A poisoned MCP server or a hidden instruction file in a repository can steer what an AI agent writes and the packages it installs. Teams are adopting AI editors faster than they’re setting up controls for them, so vetting extensions, allowlisting MCP servers, and keeping human review on AI-authored commits all belong in the same space as SAST. ## **Third-party code takes a different path into your build** The open source packages you consume make up the bulk of a typical application and arrive in `node_modules` or a virtual environment, outside your source tree. First-party code often provides the connective tissue between open source dependencies. SAST reads your source code, and it skips dependency folders like `node_modules` by default, so a compromised package doesn’t necessarily pass through it. The package’s `postinstall` script doesn’t appear in a pull request diff or a SAST report. It runs with the full privileges of whoever ran the install, on a developer workstation or a CI runner, the moment the package lands. Your first-party code and your dependencies travel separate routes into your environment: they meet at the build, and each needs its own controls. [Slopsquatting](https://cloudsmith.com/blog/slopsquatting-and-typosquatting-how-to-detect-ai-hallucinated-malicious-packages) illustrates this situation. Slopsquatting is where an AI model hallucinates a package name that seems legitimate but doesn’t exist. Attackers track these hallucinations, create malicious packages with the hallucinated name, and publish them on public registries. The next time an AI assistant writes an import for a package with a hallucinated name, it is now available and gets pulled. The import line SAST sees is well-formed and unremarkable, and now the application relies on that package. SAST has no way to verify whether the slopsquatted package is legitimate, because the package isn’t in your repository. If the developer installs it locally to try out the assistant’s suggestion, its install script runs before any commit reaches a SAST check. ## **Stolen secrets keep supply chain worms moving** Secrets link the routes taken by first-party code and dependencies: a malicious dependency steals the credentials your first-party workflows use to publish and deploy. Dependency attacks target keys, tokens, and credentials, and self-replicating worms need these secrets to spread. The [Shai-Hulud](https://cloudsmith.com/blog/evolution-of-shai-hulud-worms) worm, which first appeared in September 2025, showed how the loop works. A malicious install script read environment variables and config files, queried cloud metadata endpoints, and ran TruffleHog itself to find credentials on the infected machine. The worm then used stolen npm tokens to publish infected versions of the victim’s other packages. Each new victim that installed one of those malicious packages restarted the cycle. Secret scanning finds leaked credentials in code, git history, logs, and container images, whether those sit on a workstation, in a repository, or in CI output. Secret scanners read content at rest. A publish token injected into a CI runner’s environment from a secrets store hasn’t leaked anywhere, so the scanner has nothing to report. The install script that reads that environment variable runs in memory, beyond the scanner’s view. When CI jobs and publishing workflows authenticate with OpenID Connect (OIDC) federated tokens, each token is scoped to one job and expires shortly after. This shrinks the window during which secrets are valid. A malicious script that runs during that job finds nothing long-lived to steal, and a token stolen today is useless tomorrow. Trusted publishing on npm and PyPI brings short-lived OIDC tokens to public registries, so a stolen npm token can’t publish new versions on its own. Cloudsmith supports OIDC authentication for CI and for publishing to Cloudsmith, along with granular publish and consume permissions, which narrows what a compromised credential can do inside your own artifact pipeline. ## **Artifact management governs the code you install** Artifact management protects every third-party package that routes through it, at the moment it enters. This is beyond the scope of SAST. When developer machines, CI runners, and AI agents resolve packages through Cloudsmith instead of public registries, Cloudsmith evaluates each package against your organization’s policies, [written as code](https://cloudsmith.com/product/policy-management), before serving it. That happens _before_ the package’s install script runs and before it lands on a workstation or in a build environment. Policies can serve as a [dependency firewall](https://cloudsmith.com/blog/how-to-use-cloudsmith-as-a-dependency-firewall) and defend against threats from third-party sources that SAST can’t see: - **Known malicious packages**: Cloudsmith’s [continuous risk detection](https://cloudsmith.com/product/continuous-risk-detection) matches packages against OSV.dev data on entry, and re-checks stored packages as new threat intelligence lands. A flagged package triggers a new evaluation of your policies, which can quarantine or block the package according to the policy rules. - **Brand-new malicious versions**: a [cooldown policy](https://cloudsmith.com/product/package-cooldown-policies) holds newly published versions for a defined period, typically 3–7 days. Threat researchers report many malicious releases within days, and registries remove them. A cooldown policy works in the gap between when a malicious package is published and when an advisory exists. - **Typosquatted and slopsquatted names**: a policy that allows only approved packages stops these before anyone installs them. Cloudsmith’s [integrations](https://docs.cloudsmith.com/developer-tools/vscode) for VS Code, Cursor, and Theia let developers see package metadata and repository details directly in the IDE where they write code. Cloudsmith doesn’t scan first-party source code. That work stays with your SAST tools, and the two cover different halves of the same build: SAST checks the code your team writes, and Cloudsmith checks the code your team installs. ## **Apply both controls to the same pipeline** Keep SAST in the IDE and on every pull request. Keep secret scanning on every repository. Move publish and CI credentials to short-lived OIDC tokens so an install script has nothing durable to steal. Then route every package install through an artifact manager, the control point where your package entry paths converge. With the artifact manager as the default path, Cloudsmith evaluates the code your team _didn’t_ write against your organization’s policies before it runs. See how Cloudsmith’s [dependency firewall](https://cloudsmith.com/blog/how-to-use-cloudsmith-as-a-dependency-firewall) evaluates packages at ingestion.