Sådan virker VulnControl i virkeligheden
Skrevet til den, der bliver spurgt, om værktøjet dur — en udvikler, en systemansvarlig, en bureauchef eller den teknisk interesserede ejer, der står for vurderingen. Den dækker, hvordan software bliver identificeret, hvor sårbarhedsdata kommer fra, hvordan fund bliver tilskrevet, hvad portscanningen vil og ikke vil, og hvor grænserne går. Afsnittet om begrænsninger er ikke fyld; det er den del, der er værd at læse først.
Leder du efter udgaven i almindeligt sprog? VulnControl forretningsmæssigt
Hvad en scanning gør, i rækkefølge
Ét job pr. website, på platformens langsomme bane. To porte skal passeres, før noget som helst rører netværket, og hele kørslen lander som én samlet observation, der bliver til fund.
Server- og X-Powered-By-headere på tværs af 14 produkter, <meta generator>-taggen for 7 CMS'er, og WordPress-plugin- og temafiler med en ?ver=-parameter — med et loft, så et stort site ikke bliver til en uendelig opremsning. Hver detektion bærer en konfidensvurdering sat af kvaliteten af beviset bag den, ikke af hvor gerne vi ville have, at den passede.Hvorfor vi har vores egen kopi, og hvordan der matches i den
Spejlet bygges ud fra NVD's REST API og CISAs katalog over kendte udnyttede sårbarheder, opdateret hver nat på en dedikeret tråd, så en kørsel på flere timer ikke kan forsinke noget andet på platformen. At matche mod det er det vigtigste designområde i produktet — og dér, hvor billige scannere fejler.
Matchet på formelle identifikatorer, ikke på ord
Versionsintervaller høstes kun fra CPE-poster, hvis vendor:product-par står i det erklærede sæt for produktet, og kun for CPE'er af applikationstypen. Leverandørhalvdelen er afgørende: http_server tilhører både Apache, Oracle og IBM, så at matche på produktnavnet alene ville arkivere Oracles versionsintervaller under Apaches httpd.
Hændelse ét: hvordan tekstsøgning gav 110 falske kritiske fund
En tidlig udgave hentede data via nøgleordssøgning — en fritekstsøgning i CVE-beskrivelser — så hvert versionsinterval i enhver CVE, der bare nævnte nginx, blev gemt, som om det var nginx'. Da downloadet blev rettet, matchede nginx 1.24.0 110 CVE'er, den ikke har, de fleste vurderet kritiske. Rettet med CPE-filtrering, plus at intervaller uden grænser bliver sprunget over frem for at blive behandlet som "rammer alt". Efterprøvet bagefter: nginx 1.24.0, nul match.
Hændelse to: et falsk "rent", hvilket er værre
Senere stod nginx rent på ét site, mens et andet — samme server, samme version — viste rigtige huller. Tre årsager faldt sammen, og ingen af dem var CPE-filteret: nøgleordssøgningen havde også overset CVE'er, hvis beskrivelser aldrig bruger produktnavnet, herunder HTTP/2 Rapid Reset; en leverandør-CPE-variant manglede; og serveren skjulte sin version, hvilket gav et tavst grønt. Alle tre rettet, og der findes en regressionstest opkaldt efter det hul, der fik en rigtig nginx til at se ren ud.
Versionsopløsning for værter, der skjuler den
At slå versionsvisning fra er både almindeligt og fornuftigt, men det betyder, at en komponent matcher nul CVE'er og læses som sikker. Hver ægte detektion bliver husket pr. værtsadresse og produkt, så en komponent uden version kan arve den seneste version, der reelt er set på samme offentlige adresse — én vært er én binær. Kun ægte detektioner bliver gemt, så nedarvningen aldrig kan fodre sig selv, og oprindelsen når helt frem i brugerfladen: du kan se, om en version er observeret eller nedarvet.
Lave alvorligheder bliver aldrig hentet ind
Bevidst. Spejlet kan slet ikke melde dem, fordi en rapport polstret med småting er en rapport, ingen når til ende. Det er et valg, og det er en begrænsning — sagt her frem for skjult.
Oprydning, der ikke kan slette det, den lige har skrevet
Forældede poster fjernes kun, hvis en hentning rent faktisk blev færdig, og skæringstidspunktet kommer fra databasens ur frem for applikationens — et ur få sekunder foran ville ellers slette de rækker, synkroniseringen lige havde skrevet. Det kuraterede grundsæt lægges på igen efter hver synkronisering, fordi en filtreret hentning med rette ikke gendanner det hele.
Den laver almindelige forbindelser og læser det, tjenesterne selv byder ind med
Skellet mellem rekognoscering og angreb er hele grundlaget for, at det her kan køre automatisk mod en kundes produktionssite. Det er håndhævet i koden, ikke i en politik.
Hvad der bliver rejst, og hvor hårdt
| Fund | Hvad der udløser det | Alvorlighed |
|---|---|---|
| Sårbar komponent | Et fundet produkt og en version, der matcher en eller flere CVE'er | Den værste matchede CVE — hævet til mindst høj, når den står i kataloget over aktivt udnyttede |
| Eksponeret databaseport | En databasetjeneste, der svarer fra det offentlige internet | Kritisk, fast |
| Eksponeret admin-port | Fjernadgang eller et administrativt panel, der kan nås offentligt | Høj, fast |
| Eksponeret følsom fil | En konfigurationsfil, backup, miljøfil eller lignende, der kan hentes offentligt | Den værste af de fundne filers egne alvorligheder |
| Serveren afslører sig selv | Et produkt er identificeret, men versionen kunne ikke fastslås | Informativ — en ukendt version er hverken en frikendelse eller en sårbarhed |
Beskrivelserne bærer deres egne forbehold: et aktivt udnyttet match siger det, og et match lavet mod en ubekræftet version siger, at den måske allerede er lappet. Nul matchede CVE'er meldes som sundt — aldrig som et opfundet problem.
Det tæller med i din Trust Score
VulnControl-fund indgår i platformens samlede Trust Score sammen med alt andet, så en alvorlig eksponering flytter det tal, din oversigt åbner med, frem for at ligge i en silo, du selv skal huske at besøge.
I platformen, ikke i din indbakke
Sårbarhedsfund giver besked inde i platformen og sender ikke mails. Det er samme princip som prioriteringen selv: at adskille din huskeliste fra "det her bliver angrebet nu" er ingenting værd, hvis bunken mailer dig alligevel.
Hvad VulnControl ikke ser — og ikke kan se
Sagt her frem for opdaget senere. En køber, der selv finder en begrænsning, holder op med at stole på alt andet på siden — og i et sikkerhedsværktøj er den mistillid den rigtige reaktion.
Kun observation udefra
Det identificerer, hvad software fortæller om sig selv, og hvad åbne porte afslører. Software, der ikke fortæller noget, og alt, der ikke er eksponeret mod internettet, er usynligt. Til blikket indefra — din egen kode og de pakker, den afhænger af — er det CodeControl
En udvalgt produktliste, ikke hele NVD
39 udbredte produkter: CMS- og e-handelsplatforme, web- og applikationsservere, runtimes, fjernadgangsværktøjer, databaser, mailservere og de almindelige JavaScript-biblioteker. Mere obskure produkter er ikke dækket, og rapporten lader ikke som om. Ét framework er bevidst udeladt, fordi sårbarhedsdatabasen ikke har en brugbar identifikator for det, så en kortlægning aldrig ville kunne give andet end nul match.
"Sårbar" betyder, at versionen har et offentliggjort hul
Ikke at der har været indbrud, og ikke altid at hullet reelt kan nås i praksis — nogle sårbarheder kræver opsætninger, du ikke bruger. Det melder, hvad der kan vides udefra, hvilket også er det, en angriber ser, før de beslutter, om du er tiden værd.
Backportede rettelser fra distributioner er usynlige
Versionssammenligning er numerisk, så en distributions backportede build sammenlignes som lig med den opstrøms version, den er bygget fra. En Debian- eller Ubuntu-pakke kan bære rettelsen og alligevel melde det gamle nummer. Derfor siger et ubekræftet match det i sin egen beskrivelse frem for at fastslå, at du er sårbar.
Vagt beskrevne CVE'er springes over
En sårbarhedspost, der påstår at ramme alle versioner nogensinde, behandles som mangelfulde data frem for som en påstand, og poster, der kun gælder forhåndsudgivelser, springes over frem for at blive matchet mod almindelige udgaver. Begge valg bytter lidt dækning for præcision, og begge betyder, at nogle rigtige — men vagt dokumenterede — huller ikke dukker op.
Et hul, vi hellere nævner end skjuler
Fulde scanninger kører hver fjortende dag. Begynder et hul i software, du kører, at blive udnyttet i morgen, er det den næste planlagte scanning, der opdager det — op til to uger. Du kan sætte en scanning i gang i hånden i mellemtiden, og det her er kendt arbejde: CodeControl løser præcis det samme med et natligt gentjek mod den gemte fortegnelse, og den tilgang hører også til her.
WordPress-plugin-huller er underdækkede
Vi opremser dine plugins og temaer, men den nationale database dækker plugin-sårbarheder dårligt, så match dér er tyndere end for kernesoftware. Et dedikeret plugin-feed er den kendte løsning og er ikke bygget endnu.
Ikke en penetrationstest
Det forsøger ikke at udnytte noget, logge ind nogen steder eller sende ondsindet input. Har du brug for, at nogen aktivt prøver at bryde ind, er det en anden opgave med en anden risikoprofil — og den bør laves af mennesker, med en kontrakt.
Hold det op mod det, I bruger i dag
Kører I allerede en ekstern scanner, er den brugbare sammenligning præcisionen i tilskrivningen: hvor mange af dens kritiske fund er reelt jeres, og siger den til, når den ikke kunne fastslå en version?