Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

sota-network-security

Étoiles6

Forks2

Mis à jour10 juillet 2026 à 04:34

State-of-the-art network security as a discipline (2026) for BOTH designing/building secure networks AND auditing segmentation and exposure. Use for zero-trust architecture, network segmentation and blast-radius control, Kubernetes NetworkPolicy/CiliumNetworkPolicy depth, service mesh and mTLS, edge/ingress/egress security (WAF, egress allowlisting, metadata-endpoint blocking), DNS/TLS/PKI transport and certificate lifecycle, and remote access (WireGuard, ZTNA, bastion vs identity-aware proxy). Triggers — network security, zero trust, ZTNA, microsegmentation, east-west traffic, lateral movement, NetworkPolicy, default-deny, Cilium, Hubble, service mesh, mTLS, Istio, Linkerd, SPIFFE, ingress, egress, WAF, CRS, Coraza, egress gateway, FQDN allowlist, IMDS, 169.254.169.254, DNS firewall, DNSSEC, DoH, TLS 1.3, ACME, step-ca, private CA, WireGuard, bastion, identity-aware proxy, DDoS, segmentation audit. Owns SECURITY posture on top of cloud network setup (sota-cloud-infrastructure owns VPC/subnet/DNS setup).

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

martinholovsky

martinholovsky/SOTA-skills

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Analystes en sécurité de l'informationProfessions informatiques et mathématiques·SOC 15-1212

Explorateur de fichiers

7 fichiers

SKILL.md

readonly

Plus depuis ce dépôt

même dépôt

sota-docs-workflow

martinholovsky/SOTA-skills

State-of-the-art documentation and engineering-collaboration guidance (2026) covering documentation architecture (Diátaxis, docs-as-code, READMEs, runbooks, onboarding, AI-readable docs), API/reference docs and changelogs, and the team workflow around code: pull requests, code review conduct, commit discipline, branching, and releases. Use when writing or structuring any documentation AND when auditing docs quality, and when designing or auditing collaboration workflow. Not for in-product UI microcopy (use sota-ux-writing) or marketing/landing-page copy (use sota-copywriting). Trigger keywords: documentation, docs, README, API docs, docstring, changelog, release notes, migration guide, code review, pull request, PR description, commit messages, conventional commits, branching, semver, onboarding, runbook, AGENTS.md, llms.txt, spec-driven development, SDD, Spec Kit, Kiro, specification, acceptance criteria, steering files.

2026-07-166

sota-api-design

martinholovsky/SOTA-skills

State-of-the-art API design and audit guidance (2026) covering REST/HTTP, GraphQL, gRPC, WebSockets/SSE/realtime, webhooks, versioning/evolution, and API security/operations. Use when designing or building any API surface (endpoints, schemas, protos, realtime channels, webhook senders/receivers) AND when auditing/reviewing existing APIs for correctness, evolvability, security, and operational robustness. Not for browser UI, rendering, or client-framework concerns — use sota-web-frameworks or sota-frontend-design. Trigger keywords: API, REST, GraphQL, gRPC, endpoint, websocket, SSE, realtime, WebRTC, webhook, versioning, OpenAPI, pagination, idempotency, rate limit, problem+json, protobuf, deprecation.

2026-07-166

sota-async-concurrency

martinholovsky/SOTA-skills

State-of-the-art rules for writing and auditing asynchronous and concurrent code across runtimes (Python asyncio, JS/Node, Go, Rust, JVM). Use when building anything with async/await, threads, processes, event loops, task groups, channels, or queues — and when auditing existing code for race conditions, deadlocks, leaked tasks, blocked event loops, missing cancellation, or backpressure failures. Not for latency/throughput profiling and optimization — use sota-performance. Trigger keywords: async, await, concurrency, parallelism, threads, race condition, deadlock, event loop, channels, queues, semaphore, mutex, cancellation, timeout, backpressure, task group, goroutine, tokio, asyncio.

2026-07-166

sota-cli-ux

martinholovsky/SOTA-skills

State-of-the-art CLI and developer-tool UX guidance (2026) covering command and flag design, output and interaction (stdout/stderr, --json, TTY detection, exit codes, prompts), runtime behavior and lifecycle (signals, dry-run, idempotency, XDG paths, completions, telemetry), and distribution (packaging, checksums, docs). Use when designing or building any command line tool, subcommand, TUI, or developer tool — in any framework (argparse, click, typer, clap, cobra, oclif, commander) — AND when auditing an existing CLI for usability, scriptability, and compatibility. Not for shell-script correctness or security — use sota-shell-scripting. Trigger keywords: CLI, command line tool, flags, subcommands, terminal output, TUI, developer tool, argparse, clap, cobra, exit code, shell completion, man page, stdin, stdout.

2026-07-166

sota-databases

martinholovsky/SOTA-skills

State-of-the-art database engineering rules (2026) for designing, building, and auditing data layers. Covers engine selection, schema modeling, migrations, query and index craft, transactions and concurrency, reliability and scale, security, and vector/AI workloads. Use when designing a new data layer, writing or reviewing schemas/migrations/queries, debugging slow or contended database workloads, or auditing an existing database for correctness, performance, and security. Not for ETL or streaming data pipelines — use sota-data-engineering. Trigger keywords: database, SQL, Postgres, schema, migration, index, query, ORM, transaction, NoSQL, Redis, vector DB, pgvector, replication, partitioning, connection pool, RLS, EXPLAIN, deadlock, sharding, caching, SurrealDB, SurrealQL, Qdrant, multi-model, graph database.

2026-07-166

sota-devsecops

martinholovsky/SOTA-skills

State-of-the-art DevSecOps and software supply chain security (2026). Applies when building or auditing CI/CD pipelines, GitHub Actions workflows, supply chain controls, SBOM generation, SAST/secret-scanning gates, dependency management, container builds, container/artifact registries, IaC (Terraform), GitOps, and deployment strategy. Trigger keywords: CI/CD, pipeline, GitHub Actions, supply chain, SBOM, SAST, dependency, container build, container registry, registry security, Zot, Harbor, ECR, GAR, ACR, GHCR, immutable tags, pull-through cache, IaC, Terraform, deployment, provenance, SLSA, cosign, dependabot, renovate. Use for BOTH setting up new pipelines and auditing existing ones. Not for application code vulnerabilities (use sota-code-security) or in-cluster runtime hardening (use sota-kubernetes).

2026-07-166

name

sota-network-security

description

SOTA Network Security

Purpose

This skill encodes the 2026 state of the art for network security as a discipline: how to verify rather than trust, contain blast radius, encrypt traffic in motion, control what enters and leaves, and secure the naming and transport plumbing (DNS, TLS, PKI). Every rule exists to prevent a real failure class — lateral movement after one foothold, plaintext credentials on the wire, an over-broad rule that exposes a secrets store to the world, a renewal nobody automated, or an SSRF that reaches the cloud metadata endpoint.

Ownership — reference siblings, do not duplicate:

sota-cloud-infrastructure (rules/03 networking) owns cloud-provider network setup: VPC/subnet layout, CIDR/IPAM, route tables, LB/CDN provisioning, registrar hygiene, DNS zone setup. This skill owns the security posture layered on top and the on-prem / Kubernetes / mesh side.
sota-kubernetes owns admission control and RBAC — where NetworkPolicy is admitted and CNI enforcement is wired; this skill owns the policy content and depth.
sota-identity-access owns SPIFFE/SPIRE workload identity issuance, ZTNA user identity, and the identity-aware proxy's auth plane; this skill consumes those identities for network authorization.
sota-detection-engineering owns network IDS (Suricata), DNS-exfil detection, and flow-log detection content; this skill produces the telemetry (Hubble flows, flow logs) it consumes.
sota-sandboxing (rules/02–03) owns single-host nftables/seccomp and container hardening; this skill owns the inter-host / cluster-wide fabric.
sota-code-security (rules/01 SSRF, rules/05 CORS/CSP), sota-api-design (rules/07 rate limiting), sota-secrets-management (TLS private keys) — referenced where they intersect.

BUILD mode

Use when designing or extending a secure network (zero-trust plan, NetworkPolicy set, mesh rollout, ingress/egress controls, PKI/DNS posture, remote access).

Establish context first: on-prem vs cloud vs hybrid; CNI and orchestrator (e.g. on-prem Talos K8s + Cilium); existing PKI (step-ca), edge (Caddy + CRS WAF, Cloudflare in front); data sensitivity; who needs remote access. A 3-node homelab and a regulated fleet get different answers from the same rules.
Read the matching rules file before writing config. Segmentation (rules/02) precedes policy detail; identity-aware access (rules/01) frames everything.
Default-deny in both directions, always. Ingress and egress deny by default, per namespace and per zone. Every allow is explicit, justified in a comment, and references identity (workload identity, label selector, SG/service account) — never a bare CIDR or world entity.
Encrypt every hop that crosses a trust boundary. No plaintext credentials, JWTs, or DB traffic on the pod/internal network — mTLS via mesh or TLS terminated close to the workload.
State the failure mode and the blast radius of what you propose. "If this pod is popped, it can reach X and Y" belongs in the design, not the postmortem.
Produce policy as code (NetworkPolicy/CiliumNetworkPolicy YAML, mesh AuthorizationPolicy, nftables, ACME/cert-manager manifests) — never click-ops, never "we'll lock it down later."

AUDIT mode

Use when reviewing an existing network for segmentation gaps and exposure.

Process: inventory the fabric (zones, namespaces, CNI policies, mesh config, ingress/egress paths, DNS zones, certs, remote-access entry points); walk the Audit checklist at the end of each relevant rules file; confirm reachability before reporting — render the effective policy, run a probe (kubectl exec ... curl, Hubble flow query, nmap), read the actual rule. Do not infer exposure from a resource name.

Severity conventions

Severity	Meaning	Examples
Critical	External or any-workload party can reach a sensitive service or read traffic now	Secrets store / DB / registry reachable from a `world`/`0.0.0.0/0` entity; plaintext DB creds or JWTs on the wire (sniffable from any pod); SSH open to the internet on a prod host; admin/dashboard reachable unauthenticated from outside
High	One foothold from broad lateral movement, or a guaranteed exposure/outage class	"Default-deny" that actually allows all intra-cluster traffic; no egress control (free C2/exfil path); flat L2/L3 network with no segmentation; manual cert renewal on a public endpoint; mTLS in `PERMISSIVE` everywhere with plaintext still flowing
Medium	Weakens containment, transport security, or recovery	Ingress-only default-deny (egress still open); CIDR-based internal rules that rot on re-IP; TLS 1.0/1.1 or weak ciphers allowed; no FQDN egress filtering where it's warranted; WAF in detection-only mode; no Hubble/flow visibility
Low	Hygiene, drift, headroom	Inconsistent policy labels; over-scoped but internal-only allow; missing HSTS; no CAA record; DNSSEC undecided
Info	Context for the reader, no action implied	Mesh is overkill for a 2-service app (just use TLS); ANP/BANP still alpha — pin behavior

Severity = reachability (anonymous internet > any-workload east-west > same-namespace > insider) × impact (traffic read / sensitive-service compromise > lateral movement > availability).

Finding format

file:line | rule | severity | effort | fix

file:line — the policy/manifest/config and line (e.g. netpol/baseline.yaml:14, Caddyfile:30); for runtime-only findings name the resource (ns/payments | cilium effective).
rule — the rules-file rule id (e.g. rules/03 R4 or R-egress-default-deny).
severity — Critical / High / Medium / Low / Info.
effort — trivial / small / medium / large (eng effort to fix).
fix — the specific change (the policy diff, the directive, the mesh stanza).

Group repeated instances (e.g. 12 namespaces with no egress policy) into one finding with a count.

Rules index

File	Read this when...
rules/01-zero-trust-architecture.md	Establishing/auditing the model: never-trust-always-verify, PDP/PEP, identity-aware access over network location, ZTNA vs VPN, de-perimeterization, identity-aware proxy (BeyondCorp)
rules/02-segmentation-blast-radius.md	Designing/auditing zones and tiers, north-south vs east-west, the flat-network and over-broad-rule (`any`/`0.0.0.0/0`/`world`) traps, microsegmentation, lateral-movement containment, firewall/SG default-deny, remote access (WireGuard, bastion vs IAP)
rules/03-k8s-network-policy.md	Writing/auditing Kubernetes NetworkPolicy, CiliumNetworkPolicy, the namespaced default-deny (ingress AND egress) pattern, the "default-deny that isn't" trap, ANP/BANP, L7/identity policy, DNS-aware egress, egress gateways, Hubble visibility
rules/04-service-mesh-mtls.md	The plaintext-internal-traffic problem, choosing/auditing a mesh (Istio sidecar vs ambient, Linkerd, Cilium mesh), mTLS everywhere, mesh authorization policy, SPIFFE identity, and deciding mesh vs plain TLS
rules/05-edge-ingress-egress.md	WAF (CRS/Coraza), ingress/API-gateway hardening, TLS termination + re-encryption, trusted-IP handling behind Cloudflare, DDoS posture (edge scrubbing + self-hosted kernel hardening: SYN cookies/synproxy, conntrack, rp_filter, no open UDP reflectors), egress as a first-class control, FQDN allowlisting, blocking the metadata endpoint, the SSRF-meets-egress chain
rules/06-dns-tls-pki.md	DNS security (DNSSEC, RPZ/DNS firewall, DoH/DoT, split-horizon, CAA, tunneling), TLS posture (1.3, ciphers, HSTS, OCSP), shrinking cert lifetimes + ACME automation, internal PKI (step-ca), short-lived certs, pinning tradeoffs, email authentication & anti-spoofing (SPF/DKIM/DMARC, MTA-STS/DANE, bulk-sender rules)

Cross-cutting tasks read multiple files: a full network audit touches all six; "lock down our cluster" is rules/02 + rules/03 (+ rules/04 if a mesh exists).

Top 10 non-negotiables

Verify, don't locate-trust. Access decisions bind to authenticated identity (workload or user) and posture, not to "it's on the internal network." A packet's source subnet is not a credential. (NIST SP 800-207; CISA ZTMM v2.0.)
Default-deny in BOTH directions. Every namespace/zone denies ingress and egress by default; allows are explicit and identity-scoped. An ingress-only default-deny leaves the exfil door open.
No any / 0.0.0.0/0 / world to sensitive services. A secrets store, DB, registry, or admin UI reachable from a broad entity is a Critical finding — render the effective rule and prove the path, don't trust the rule's name.
The "default-deny" must actually deny. A baseline policy that allows all intra-cluster traffic is not default-deny; verify with a probe (cross-namespace curl should fail).
Encrypt internal traffic. DB creds, JWTs, and app traffic crossing the pod/host network ride mTLS or TLS — never plaintext ws:///http:///unencrypted DB protocol. Mesh in STRICT, not permissive-forever.
Egress is a control, not a default-open pipe. Default-deny egress, FQDN/IP allowlists, egress gateways/proxies for sensitive zones; block the cloud metadata endpoint (169.254.169.254, fd00:ec2::254) at the pod/host. This is the C2/exfil and SSRF-pivot chokepoint.
Microsegment east-west. Contain blast radius so one popped workload can reach only its declared dependencies. Flat networks turn a single foothold into a cluster-wide incident.
Identity-aware access for humans. ZTNA / identity-aware proxy (per-request identity + device posture) over flat VPN access; if VPN, WireGuard with per-peer keys, never SSH open to the world.
Certs are automated and short-lived. Every cert (public and internal) is ACME/cert-manager issued and auto-renewed. CA/Browser Forum caps public certs at 200 days (2026-03-15) → 47 days (2029-03-15); manual renewal is now an outage generator.
Flows are visible. You can answer "who talked to whom" — Hubble / flow logs / mesh telemetry on, exported to detection (sota-detection-engineering). You cannot secure traffic you can't see.

Operating notes

Principles first, then the user's stack (Talos K8s + Cilium, step-ca, Caddy+CRS, Cloudflare); name alternatives when the stack is unknown.
Verify versions and API status against current docs before committing them — CNI features, mesh GA status, the ANP/BANP/ClusterNetworkPolicy API state, CRS version, and the CA/B cert schedule all move faster than this text. Be version-agnostic where a claim is unpinnable.
When this skill and a compliance mapping conflict, state both; do not silently relax a control.