# Sysdig Secure — Platform Guide

> **Intro:** Sysdig Secure is not just “Falco with a UI.” It is a broader cloud-security platform that combines runtime detection, vulnerability management, posture, admission control, investigation, and response workflows. The open-source roots matter, but teams evaluating Sysdig need to understand clearly where open source ends and the commercial platform begins.
>
> **What this page includes**
>
> * what Sysdig Secure is and who it is for;
> * open-source versus commercial boundaries;
> * install and integration paths;
> * common findings and report patterns;
> * troubleshooting and legacy notes.

## What Sysdig Secure is

Sysdig Secure is a commercial cloud and runtime security platform built around workload visibility, threat detection, vulnerability management, posture, and response. In Kubernetes and container-heavy estates it is often evaluated when a team wants one platform for:

* runtime detections;
* image and runtime vulnerability findings;
* deploy-time policy checks;
* Kubernetes posture and admission enforcement;
* incident investigation with workload context.

## Who it is for

Sysdig Secure is usually most relevant for:

* cloud and platform security teams;
* DevSecOps teams running Kubernetes at scale;
* product security teams that need runtime and image context together;
* SOC or detection engineers who need cloud-native runtime signals with response hooks.

## Is there an open-source version?

### Short answer

**Sysdig Secure itself is commercial.**

### What is open source in the Sysdig ecosystem?

The most important open-source projects around it are:

* **Falco** for cloud-native runtime threat detection;
* **sysdig OSS** for system visibility history and troubleshooting;
* **Wireshark** and **Stratoshark** in the wider open-source ecosystem Sysdig actively supports.

For many teams, the best way to think about it is:

* **Falco** = open-source runtime engine and rule ecosystem;
* **Sysdig Secure** = platform workflows, SaaS backend, findings, correlation, admission, policy management, and response UX.

## Risks Sysdig Secure helps address

### Runtime threat detection

Suspicious process behavior, shell activity, drift, and container runtime anomalies.

### Vulnerability prioritization

Not just “CVE exists,” but findings across pipeline, registry, and runtime resources.

### Deploy-time prevention

Admission Controller can block workloads based on vulnerability or posture policy.

### Drift and immutability violations

Sysdig can detect drifted binaries or modified runtime state that diverges from the image baseline.

### Investigation and response

Events, captures, exports, and response hooks help move from signal to action faster.

## Key product building blocks to understand

### Shield

Shield is the current installation and runtime collection model for Kubernetes and hosts.

### Vulnerability Management

Image and runtime findings backed by SBOM analysis and policy evaluation.

### Admission Controller

Deployment-time control for vulnerability and posture policy enforcement.

### Runtime Policies

Falco-based or Falco-aligned runtime detections, scope, severity, and response actions.

### Drift Detection

Policies that detect and optionally prevent execution of binaries introduced after the container started.

### Events Feed

The primary event review and triage surface for runtime detections and related security events.

## Install on Kubernetes with Helm

A current Kubernetes installation pattern uses the `shield` chart.

### Minimal `values.yaml`

```yaml
cluster_config:
  name: prod-eks-main

sysdig_endpoint:
  region: us1
  access_key: REPLACE_ME

features:
  monitor:
    kubernetes_events:
      enabled: true
    kube_state_metrics:
      enabled: true

host:
  driver: universal_ebpf
```

### Install

```bash
helm repo add sysdig https://charts.sysdig.com
helm repo update
helm upgrade --install --atomic --create-namespace   -n sysdig   -f values.yaml   shield   sysdig/shield
```

## System and network prerequisites

Before installation, confirm:

* supported platform or Kubernetes distribution;
* account and access key;
* outbound access to port **443** and **6443**;
* in-cluster access to port **12000** for KSPM and **4222** for container vulnerability management where required.

## Admission Controller example

### Install with admission enabled

```bash
helm upgrade --install --atomic --create-namespace   --namespace sysdig   --set cluster_config.name=ac-cluster   --set sysdig_endpoint.region=us1   --set sysdig_endpoint.access_key=$SYSDIG_ACCESS_KEY   --set features.admission_control.enabled=true   --set features.admission_control.container_vulnerability_management.enabled=true   --set features.admission_control.posture.enabled=true   shield sysdig/shield
```

### Verify webhook registration

```bash
kubectl get validatingwebhookconfigurations | grep shield
kubectl describe validatingwebhookconfigurations shield-cluster-admission-control
```

### Important rollout note

Admission Controller starts in **dry run** by default. That is a good starting behavior because it lets teams see what would be blocked before enforcing.

## Typical deployment and integration patterns

### Kubernetes runtime + image security

Common path:

* install Shield;
* enable runtime policies and vulnerability findings;
* route events to Slack, SIEM, or case-management;
* pilot Admission Controller in dry run;
* only later move selected policies to enforcement.

### Registry or pipeline scanning

Use Sysdig image scanning with CI or registry workflows when the team wants a single findings model across pipeline, registry, and runtime.

### Cloud + runtime correlation

Use runtime events next to cloud audit data to answer questions like:

* which workload ran the suspicious process?
* was the image already known vulnerable?
* what cluster, namespace, or account did it affect?

## What findings look like conceptually

### Vulnerability finding example

```
CVE-2025-12345
Resource: deployment/payments-api
Image: registry.example.com/payments-api:1.14.2
Package: openssl
Severity: Critical
Exploit Available: true
Fix Available: true
Runtime In Use: true
Zone: Production
```

### Runtime event example

```json
{
  "policy": "Unexpected Shell in Production",
  "severity": "high",
  "cluster": "prod-eks-main",
  "namespace": "payments",
  "workload": "payments-api",
  "container": "payments-api-7c9d6d8f5f-2lz7n",
  "proc": "/bin/sh",
  "cmdline": "sh -c cat /etc/passwd",
  "user": "root",
  "source": "runtime"
}
```

### Drift event example

```
Policy: Drift Detection
Rule: Binary Drift
Container: checkout-api
Namespace: production
Path: /tmp/curl
Action: prevent execution
Severity: high
```

These examples are illustrative so the page stays portable across product versions.

## Example report views engineers care about

### 1. Vulnerability overview

Best for:

* what are the worst exploitable findings?
* which active runtime resources are affected?
* where is there a fix available right now?

### 2. Vulnerability findings table

Best for:

* CVE × resource × package triage;
* grouping by image, CVE, or runtime resource;
* focusing on exploitable, in-use, or fixable findings.

### 3. Events Feed

Best for:

* recent runtime detections;
* slicing by clusters, namespaces, workloads, or policies;
* exporting event details as JSON/CSV or opening a response flow.

## Typical findings and vulnerability examples to explain to teams

### Example 1 — shell spawned in a production container

Meaning:

* possible operator action;
* possible attacker foothold;
* investigate parent process, actor, and workload role.

### Example 2 — drifted binary execution

Meaning:

* image immutability broke;
* could be package install, curl-dropper, or debug artifact;
* review deployment model and incident context.

### Example 3 — critical CVE in runtime workload with fix available

Meaning:

* not all CVEs are equal;
* prioritize if the package is in use, exposed, exploitable, and fixable.

### Example 4 — posture violation blocked at admission

Meaning:

* shift-left enforcement worked;
* validate whether the rule is correctly scoped before broad rollout.

## Troubleshooting checklist

### Agent or shield not reporting

Check:

* access key correctness;
* license/subscription state;
* outbound connectivity to `collector.sysdigcloud.com`;
* port **6443** reachability;
* agent logs in `/opt/draios/logs/draios.log`.

### Admission Controller not affecting workloads

Check:

* account feature enabled;
* webhook registration present;
* policy assignment scope;
* namespace exclusions;
* `dry_run` still enabled.

### Duplicate or strange host identity

Check:

* duplicate MAC addresses in virtualized estates;
* if needed, use a unique `machine_id_prefix`.

### Nothing is being blocked

Most common reasons:

* still in dry-run mode;
* `failure_policy` or scope is too permissive;
* wrong namespaces or clusters assigned;
* policy severity tuned but no blocking action configured.

## Legacy versus current notes

| Topic                 | Older pattern                        | Current reading                                                    |
| --------------------- | ------------------------------------ | ------------------------------------------------------------------ |
| deployment chart      | `sysdig-deploy` chart                | current docs center on the `shield` chart                          |
| agent networking      | older references to port 6666        | current agent path uses port 6443                                  |
| admission enforcement | older scanner-centric flow           | current docs unify posture and vulnerability admission with Shield |
| drift naming          | `Container Drift` or `Drift Control` | current naming is **Drift Detection**                              |
| runtime backend story | Falco-adjacent detection             | broader platform around findings, posture, admission, and response |

## When Sysdig Secure is a good fit

It is a strong fit when you want:

* runtime + vulnerability + admission in one platform;
* one product view across clusters and runtime resources;
* SaaS workflow on top of Falco-driven ideas;
* a faster path to policy, findings, and response than stitching everything manually.

## When open source alone may be enough

Use Falco-first or OSS-first when:

* you mainly need runtime alerts;
* the team can operate the pipeline and response integration itself;
* you do not need commercial posture, admission, or vulnerability UX right away.

## Related pages

* [🦅 Falco for Runtime Detection — Practical Guide](/attack-paths-testing-detection-and-hardening/index/falco-runtime-detection-practical-guide.md)
* [🛎️ Runtime Detection Stack — Falco, Tetragon, and Cloud Signals](/attack-paths-testing-detection-and-hardening/index/runtime-detection-stack-falco-tetragon-and-cloud-signals.md)
* [📦 Local Artifact Repository Scanning and JFrog Xray](/devsecops-cicd-and-supply-chain/index-1/local-artifact-repository-scanning-and-jfrog-xray.md)
* [🏗️ Harbor Registry Hardening](/devsecops-cicd-and-supply-chain/index-1/harbor-registry-hardening.md)

\---*Author attribution: Ivan Piskunov, 2026 - Educational and defensive-engineering use.*


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.product-security.expert/attack-paths-testing-detection-and-hardening/index/sysdig-secure-platform-guide.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.