Overview
ShieldedStack runs inside your environment. Your organization operates the runtime infrastructure, identity provider, data stores, logs, backups, ingress, TLS, and secrets management.
The Control Plane and package proxy work together to protect dependency installs before packages reach developer workstations or CI pipelines. By routing package-manager traffic through your ShieldedStack proxy you can:
- Enforce API-key based access so only approved projects pull dependencies.
- Apply workspace policies such as allow lists, deny lists, grace periods, and runtime blocking.
- Track package download activity, project ownership, and proxy metrics inside your own deployment.
- Monitor vulnerability, outdated package, and package-risk signals without giving ShieldedStack access to your runtime data.
How the Pieces Fit
Section titled “How the Pieces Fit”Deployment URLs
Section titled “Deployment URLs”A deployment exposes two URLs, and the documentation refers to them by these names throughout.
| Placeholder | Purpose | Default port |
|---|---|---|
<portal-url> |
Browser UI, API, and MCP endpoint | 3000 |
<proxy-url> |
Package-manager proxy endpoint | 3003 |
Both are commonly placed behind an ingress, reverse proxy, and TLS certificates, in which case the deployment’s own hostnames replace the defaults.
Quick Start Checklist
Section titled “Quick Start Checklist”- Get Control Plane access - Sign in through the identity provider the deployment uses. Access is granted per tenant and workspace.
- Create or select a workspace - Use separate workspaces when environments need different policies, package filters, or alert handling.
- Generate an API key - Navigate to Settings -> API Keys and create a key for each project, repository, or deployment target that needs proxy access.
- Configure your package manager - Point npm, pnpm, yarn, pip, NuGet, Maven/Gradle, Go, Cargo, RubyGems, or Dart / pub.dev at
<proxy-url>and authenticate with the generated API key. - Set your policy - Review Settings and Settings -> Package Filters so the workspace enforces the posture you intend.
- Review risk insights - Use Overview, Alerts, Packages, and CVEs to prioritize remediation work.
Core Concepts
Section titled “Core Concepts”- Tenants group users, workspaces, and access management inside one ShieldedStack installation.
- Workspaces hold proxy policies, alert history, package activity, and configuration for a specific environment or operating boundary.
- API Keys bind each package install or scanner upload to a project name and workspace configuration. They give you ownership, policy selection, and auditability for dependency requests.
- Projects are the names attached to package activity, created by the API keys that carry them, and used to filter and report on everything else.
- Package Filters define allow or deny rules by ecosystem, package pattern, and version range. Pair filters with grace periods and minimum severity settings to block risky packages before they reach builds.
- Vulnerability Exceptions exclude a specific advisory for a specific package version. The advisory stops generating alerts and stops counting toward proxy blocking, while staying visible in an audit trail for later review.
- Notification Channels broadcast alerts to Microsoft Teams or custom webhooks so security and operations teams get notified without watching the dashboard.
Where to Go Next
Section titled “Where to Go Next”| If you want to | Read |
|---|---|
| Get a package manager routed through the proxy | Quick Start |
| Find your way around the console | Console Tour |
| Configure a specific package manager | Ecosystems |
| Decide what gets blocked, and understand why something was | Policy and Enforcement |
| Work the alert queue, acknowledge or accept findings | Alerts and Triage |
| Explore the inventory, risk scores, advisories, and licenses | Packages and Risk |
| Trace where a package version actually went | Request Logs |
| Get alerts into Teams or your own systems | Notification Channels |
| Produce an SBOM or a compliance export | Exports and SBOM |
| Set up workspaces, projects, keys, members, and permissions | Workspaces and Access |
| Inventory environments that cannot route through the proxy | Package Scanner |
| Let AI agents query workspace data | MCP Server |
A Suggested First Two Weeks
Section titled “A Suggested First Two Weeks”Rolling out enforcement on day one tends to break builds and cost you the goodwill you need for everything after. A calmer sequence:
- Route traffic first. Point one or two pipelines at the proxy in Trust then Verify mode with no grace period. Nothing is blocked; you are building an inventory.
- Watch what arrives. Within a few days the Packages, CVEs, and Licenses views describe what you actually depend on, which is usually more than anyone expected.
- Tune before enforcing. Work the alert queue once. Record exceptions where a finding is genuinely acceptable and add deny rules where it is not, so the policy you turn on reflects decisions already made.
- Turn on enforcement. Set a minimum block level and a grace period, then watch blocked events in Logs to confirm you are stopping what you meant to stop.
- Then tighten selectively. Move production or release workspaces to Verify then Trust once the rest is steady.