Dockerfilen ja buildpacks-ratkaisujen välisessä keskustelussa ei ole enää kyse pelkästään siitä, kumpi tapa tekee konttikuvien rakentamisesta helpompaa. Cloud Native Buildpacks siirtää merkittävän osan konttien tietoturvan hallinnasta yksittäisiltä sovelluskehittäjiltä alustatiimeille.
Ero korostuu erityisesti silloin, kun organisaatio ylläpitää satoja palveluita ja käytössä olevasta Linux-pohjakuvasta löytyy kriittinen haavoittuvuus. Dockerfile-pohjaisessa ympäristössä korjaus voi tarkoittaa muutoksia suureen määrään repositorioita. Buildpacks mahdollistaa tietyissä tilanteissa runtime-pohjakuvan vaihtamisen ilman sovelluksen varsinaisten kerrosten rakentamista uudelleen.
Cloud Native Buildpacks -projekti saavutti CNCF graduated-tason 17. heinäkuuta 2026. Projektin keskeinen ajatus on keskittää konttien rakentamiseen liittyviä käytäntöjä niitä hallitsevalle alustatiimille sen sijaan, että jokainen kehitystiimi ylläpitäisi omia Dockerfile-tiedostojaan.
Dockerfile hajauttaa vastuun sovelluskohtaisesti
Perinteisessä Dockerfile-mallissa pohjakuva määritellään FROM-rivillä. Jos organisaatiolla on esimerkiksi satoja erillisiä palveluita, sama tai samankaltainen määrittely voi löytyä suuresta määrästä repositorioita.
Kun pohjakuvasta löytyy kriittinen CVE-haavoittuvuus ja siitä julkaistaan korjattu versio, päivitys täytyy saada kaikkiin sitä käyttäviin sovelluksiin.
Renovaten ja Dependabotin kaltaiset työkalut voivat automatisoida päivitysten tekemistä, mutta ne eivät poista varsinaista uudelleenrakentamista. Muutettu FROM-rivi johtaa uuteen buildiin, CI-ajoon, testeihin ja lopulta uuden version käyttöönottoon.
Yhden sovelluksen kohdalla tämä ei välttämättä ole merkittävä ongelma. Satojen palveluiden ympäristössä sama prosessi moninkertaistuu nopeasti. Buildpacks pyrkii muuttamaan juuri tätä mallia.
Builder keskittää pohjakuvien hallinnan
Cloud Native Buildpacks käyttää builder-konttikuvaa, johon sisältyvät buildpackit, lifecycle-komponentit sekä rakentamisessa käytettävä pohjakuva.
Lisäksi builder sisältää viittauksen erilliseen runtime-pohjakuvaan eli niin sanottuun run imageen.
Tämä erottaa sovelluksen omat kerrokset käyttöjärjestelmän runtime-kerroksista. Kun run imagesta julkaistaan yhteensopiva ja korjattu versio, olemassa oleva sovelluskuva voidaan tietyissä tilanteissa päivittää rebase-toiminnolla.
Rebase ei rakenna sovellusta alusta asti uudelleen. Se korvaa OCI-kuvan runtime-kerrokset uuden run imagen vastaavilla kerroksilla ja päivittää kuvan manifestin sekä konfiguraation.
Käytännössä kyse voi olla erittäin kevyestä operaatiosta verrattuna kokonaisen sovelluksen uudelleenrakentamiseen.
Tämä ei kuitenkaan tarkoita, että korjattu konttikuva pitäisi siirtää automaattisesti tuotantoon. Organisaation on edelleen testattava, hyväksyttävä ja otettava päivitetty kuva käyttöön oman prosessinsa mukaisesti.
Rebase voi nopeuttaa kriittisten haavoittuvuuksien korjaamista
Rebase-mallin suurin hyöty näkyy tilanteessa, jossa haavoittuvuus sijaitsee runtime-pohjakuvassa.
CNCF TAG Environmental Sustainability -ryhmälle kirjoittanut Joe Kutner on kuvannut rebase-operaatiota käytännössä OCI-kuvan JSON-rakenteen muuttamiseksi. Operaatio voi tapahtua millisekunneissa eikä se vaadi sovelluksen lähdekoodia tai normaalia CI-rakennusta.
Tällä on merkitystä sekä suorituskyvyn että tietoturvan kannalta. Jos esimerkiksi sata palvelua käyttää samaa yhteensopivaa run imagea, alustatiimin ei tarvitse välttämättä käynnistää sataa täyttä sovellusbuildia pelkästään käyttöjärjestelmäkerroksen päivittämiseksi.
Rebasella on kuitenkin selvä rajoitus: se ei korjaa sovelluksen omissa riippuvuuksissa olevia haavoittuvuuksia.
Jos haavoittuvuus löytyy esimerkiksi sovelluksen käyttämästä kirjastosta, riippuvuus on päivitettävä ja sovellus rakennettava uudelleen normaalisti. Buildpacks ei siis poista tarvetta sovellusten riippuvuuksien hallinnalle.
Hardened builder -ratkaisuista tulee uusi kilpailualue
Buildpacks-mallin yleistyminen on samalla muuttamassa sitä, missä konttiturvallisuudesta kilpaillaan.
BellSoft julkaisi heinäkuussa 2026 yleisesti saataville hardened-version Paketo builderista. Ratkaisu perustuu yhtiön Alpaquita Linux -pohjaisiin Hardened Images -kuviin.
Tavoitteena on pienentää käytettävien pakettien määrää, käyttää oletuksena muita kuin root-käyttäjiä sekä tarjota allekirjoituksia ja SBOM-tietoja.
BellSoft kertoo julkaisevansa korjattuja kuvia tyypillisesti 24 tunnin kuluessa haavoittuvuuden julkistamisesta. Sen maksullisen Standard-tason sopimuksessa kriittisten haavoittuvuuksien korjaamiselle luvataan seitsemän päivän SLA ja muiden haavoittuvuuksien kohdalla 14 päivää.
Buildpacks ei kuitenkaan ole ainoa alue, jolla hardened-kuvista kilpaillaan.
Myös Chainguard, Docker, Wiz ja Minimus tarjoavat vähäisiin tai jopa nollaan tunnettuihin CVE-haavoittuvuuksiin tähtääviä konttikuvia.
Docker teki koko hardened image -valikoimastaan maksuttoman Apache 2.0 -lisenssillä joulukuussa 2025. Maksullisissa vaihtoehdoissa yritys myy edelleen esimerkiksi korjausaikoihin liittyviä palvelutasolupauksia.
Kun itse hardened-kuvia on saatavilla yhä useammalta toimittajalta, kilpailu siirtyy vähitellen siihen, kuinka nopeasti ja hallitusti korjaukset voidaan saada sovelluksiin asti.
Dockerfilejen ylläpito voi muodostua tietoturvariskiksi
Buildpacksin argumenttia tukee myös ongelma, joka liittyy Dockerfile-tiedostojen hajautettuun ylläpitoon.
Kun jokainen sovellustiimi vastaa omasta Dockerfilestaan, niiden käytännöt ja päivitystahti voivat eriytyä toisistaan. Osa käyttää uusimpia pohjakuvia, kun taas toisissa palveluissa vanhat versiot voivat jäädä käyttöön pitkäksi aikaa.
Dockerfile drift -ilmiötä käsittelevä tutkimus on osoittanut, että konttien build-määrittelyt voivat helposti ajautua erilleen niitä käyttävän sovelluksen todellisesta tilanteesta.
BellSoftin 250 Spring-kehittäjälle, tekniselle vetäjälle ja arkkitehdille tekemässä kyselyssä 64 prosenttia vastaajista ei myöskään tunnistanut omaa Dockerfileaan tietoturvariskiksi.
Ongelma ei rajoitu pohjakuviin. Vuoden 2025 tutkimuksessa tarkasteltiin 6 292 Docker-kuvaa, ja lähes 61 prosentissa repositorioista oli haavoittuvia sovellusriippuvuuksia jokaisessa tarkastetussa tagissa.
Juuri näihin sovellustason haavoittuvuuksiin rebase ei auta, mutta tulokset osoittavat, kuinka helposti konttien päivitykset voivat jäädä tekemättä.
Buildpacks keskittää myös riskin
Tietoturvan keskittäminen alustatiimille ei automaattisesti tee järjestelmästä turvallista.
Kun builderista tulee satojen sovellusten yhteinen rakennuskomponentti, myös siihen kohdistuva luottamus kasvaa merkittävästi. Organisaation täytyy hallita builderien allekirjoittamista, attestointeja, testaamista ja hyväksymistä.
Virhe tai toimitusketjuhyökkäys keskitettyyn builderiin voisi puolestaan vaikuttaa suureen määrään sovelluksia.
Buildpacks siis muuttaa ongelman luonnetta. Sen sijaan, että satojen kehitystiimien pitäisi ylläpitää omia pohjakuviaan oikein, huomattavasti suurempi vastuu annetaan pienemmälle joukolle platform engineering -asiantuntijoita.
Tämä voi parantaa päivitysten johdonmukaisuutta, mutta samalla keskitetyn infrastruktuurin suojaamisesta tulee entistä tärkeämpää.
Dockerfile ei ole katoamassa
Buildpacks ei sovi kaikkiin ympäristöihin. Dockerfile antaa kehittäjälle erittäin tarkan kontrollin siitä, miten konttikuva rakennetaan. Tätä tarvitaan esimerkiksi sovelluksissa, jotka käyttävät epätavallisia käyttöjärjestelmäpaketteja tai teknologioita, joille sopivaa buildpackia ei ole tarjolla.
Cloud Native Buildpacks tarjoaa image extensions -mekanismin, jolla platform-tiimit voivat lisätä build.Dockerfile- ja run.Dockerfile-vaiheita muuten standardoituun buildiin.
Tämä tuo takaisin osan Dockerfilen tarjoamasta joustavuudesta.
Samalla syntyy kuitenkin kompromissi. Run imagen laajentaminen voi heikentää tai poistaa mahdollisuuden käyttää nopeaa rebase-menetelmää. Mitä enemmän rakennusprosessia mukautetaan, sitä enemmän menetetään niitä etuja, joiden vuoksi Buildpacks-malliin alun perin siirryttiin.
Buildpacks voi lisäksi tarkoittaa hitaampia ensimmäisiä buildeja ja suurempia konttikuvia.
Konttien tietoturvan kontrollipiste on siirtymässä
Dockerfilejen ja buildpacks-ratkaisujen vertailussa keskeinen kysymys ei siten enää ole vain se, kumpi tapa on kehittäjälle helpompi. Oleellisempaa on, missä organisaatio haluaa konttien tietoturvaa koskevien päätösten tapahtuvan.
Dockerfile-mallissa vastuu on suurelta osin yksittäisissä repositorioissa ja kehitystiimeissä. Buildpacks-mallissa pohjakuvien ja niiden päivitysten hallintaa voidaan keskittää platform engineering -tasolle.
Satojen mikropalveluiden ympäristössä tällä voi olla huomattava vaikutus siihen, kuinka nopeasti kriittinen pohjakuvan haavoittuvuus saadaan korjattua koko järjestelmästä.
Samalla keskitetyn builderin ylläpitäjästä tulee entistä merkittävämpi osa ohjelmistojen toimitusketjua.
EU Cyber Resilience Actin kaltaiset sääntelyhankkeet lisäävät painetta pystyä osoittamaan, miten ohjelmistojen haavoittuvuuksia hallitaan ja korjataan. Tällaisessa ympäristössä kysymys ei ole ainoastaan turvallisen pohjakuvan valitsemisesta, vaan myös siitä, kuka vastaa sen päivittämisestä ja kuinka nopeasti korjaus saadaan tuotantoon.
Buildpacksin merkittävin muutos voikin olla juuri tämä: konttien koventamisen kontrollipiste siirtyy yksittäisestä Dockerfilesta kohti keskitetysti hallittua builderia.