PS Product SecurityKnowledge Base

🛡️ Sysdig Secure — Platform Guide, Open Source Context, Installation, and Operational Use

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

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

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

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

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

{
  "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.

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