Denne leverandør skrevet tech primer har blitt redigert av Network World å fjerne produktmarkedsføring, men lesere bør merke det vil trolig favorisere innsenderen tilnærming.

Hvis du scrambling denne uken for å installere patcher etter oppdagelsen av sikkerhetsproblemet GHOST påvirker Linux-systemer, er du ikke alene. Det faktum at vi har vært ned denne veien før gjør ikke det noe mindre frustrerende. Det var ikke så lenge siden at nyheten ble kjent om Shellshock. Og ikke lenge før det, Heartbleed.

Å være i reaktiv modus på grunn av alvorlige vekst programvare sikkerhetstrusler kan virke som den nye normalen, men du trenger ikke å godta det. Du kan gjøre mer enn bare å reagere. Hva om din organisasjon kan gjøre programvare sikkerhet forkjøpsrett, drar ut mange sårbarheter før
noen skade er gjort?

Ved å fokusere på det jeg liker å kalle "open source hygiene", kan du gjøre nettopp det mer om dette snart. Men først, la oss undersøke hvorfor GHOST gjør programvare sikkerhetseksperter så nervøs.

GHOST i Linux-maskin

Sikkerhetsproblemet GHOST i Linux GNU C Library (glibc 2.2) er et gapende en. Versjon 2.2 er optimalisert for en rekke standard Linux-distribusjoner, spesielt de som bygger på Debian Wheezy, men også på Red Hat plattform versjoner. Dette systemet befolkningen inkluderer et bredt utvalg av embedded systemer sammen med servere og stasjonære.

Det berørte API, "gethostbyname ()", er en integrert del av POSIX-standarden, som er definisjonen av UNIX-type systemer , inkludert Linux. Dette API er en del av kjernefunksjonaliteten for Linux. Den glibc-biblioteket er den primære biblioteket som brukes av alle typer programmer som kjører på Linux til å samhandle med kjernen og til å utføre kjerne input /output operasjoner. Sagt på en annen måte, går alt gjennom glibc det er som Grand Central Station.

Kanskje mest bekymringsfullt er det faktum at den utnytter kan aktiveres via godartede handlinger som for eksempel behandlingen epost. Og i motsetning til bash, som var sentral i Shellshock trussel, er glibc et rimelig godt kuratert bibliotek. Så problemet med GHOST er ikke at det ikke har vært nok øyne på koden. Faktisk er det stadig oppdatert og testet. Snarere er problemet at ikke alle av de øynene er tilstrekkelig sikkerhet-savvy.

Å ta ansvar for åpen kildekode sikkerhet

Selv med mange øyne på koden, programvare sårbarheter som GHOST og forgjengerne er uunngåelige. IT-organisasjoner er strukket tynn, prøver å gjøre mer med mindre og levere innovative programmer raskere enn noensinne. Velge åpen kildekode-komponenter som en del av utviklingsprosessen hjelper dem å oppnå disse målene. Hva mer, delta i og bidra til åpen kildekode-miljøene er en viktig del av hvordan framtidsrettet IT-organisasjoner innovere.

Så hvordan kan programvareutvikling organisasjoner balanse åpen kildekode sikkerhetsbekymringer med stasjonen for å holde nyskapende på en stadig raskere tempo?

Svaret ligger i åpen kildekode hygiene. Ved å implementere automatiserte løsninger for håndtering av åpen kildekode i hele utviklingsprosessen og på tvers av verdikjeden, organisasjoner få en kritisk fordel i overskriften av sikkerhetstrusler. Dette betyr Koden blir automatisk vetted mot sårbarhets databaser som OSVDB og NVDB, sikre at bare de mest up-to-date versjoner av disse komponentene er valgt.

Når det gjelder GHOST, ville denne tilnærmingen har gitt en av flere utfall:

- Tidligere flagging av glibc versjon 2.2 eller tidligere, med en oppfordring til å oppgradere utvikling og utplassert versjoner til versjon 2.3

- Nåværende flagging av biblioteket, basert på OSVDB. /NVDB bulletiner, for å sjekke for frarådet versjoner til og bekrefte at de riktige oppdateringene hadde blitt brukt til versjon 2.3.

I andre ord, du trenger ikke å kaste bort tid på å lete etter åpen kildekode-komponenter i din kodebasen du vet nøyaktig hvor de er og hvordan de blir brukt. Dette gir deg en praktisk veikart til rask utbedring.

Med åpen kildekode hygiene, kan organisasjonen sortere gjennom og håndtere de pågående sikkerhetstrusler, fordi usikre åpen kildekode er merket, og utbedring stier identifisert, i begynnelsen av utviklingsprosessen heller enn når prosessen er allerede i gang.

Den smarteste programvareutvikling organisasjoner i dag er å integrere open source hygiene i deres programvareutviklingen så sikkerhet er ikke lenger om utbedring, men om å være pre-emptive og proaktiv. Med denne tilnærmingen, blir programvaren livssyklus mye mer håndterlig.