Wolfi: la distribución base pensada para contenedores

Probado con wolfi-base (apk-tools 2.14.10, glibc 2.44) · apko 1.4.1 · cosign 3.1.3 · Grype 0.118.0 · arm64 · verificado 2026-09-16

Actualizado: 2026-09-16

Wolfi es la distribución sin kernel que Chainguard presentó el 22 de septiembre de 2022 y que hoy sirve de base a Chainguard OS y a sus imágenes de contenedor. La usan también equipos que quieren controlar su cadena de suministro sin depender del calendario de Debian ni de las particularidades de musl en Alpine. El 16 de septiembre de 2026 volví a comprobar en arm64 lo que cuenta esta guía: wolfi-base, apk, apko, cosign y Grype. Las salidas que ves son las reales, y cada sección dice lo que no pudo ejecutarse aquí.

Puntos clave

• Wolfi es una distribución Linux sin kernel para el espacio de usuario de contenedores. No publica versiones numeradas: su /etc/os-release sigue marcando VERSION_ID="20230201".

• Usa glibc 2.44 en lugar de musl, así que acepta las ruedas manylinux de Python, como las de torch y onnxruntime, que no tienen variante para musl.

• Cada paquete incluye su SBOM en formato SPDX, el índice de apk va firmado con RSA y las imágenes de Chainguard se firman con Sigstore cosign.

• La publicación continua se mide en horas: el paquete arm64 de OpenSSL 3.6.4 se compiló 1 h y 32 min después de publicarse la versión original.

• El repositorio ofrece 15 119 paquetes (106 818 compilaciones) y apk search es la herramienta para buscarlos y listarlos.

• El coste de adopción es real: Wolfi usa apk-tools 2.14.10 y Alpine 3.24 ya va por la 3.0.6. Además, las versiones antiguas se borran a los 6 meses y las imágenes gratuitas de Chainguard solo publican su última compilación.

Qué es Wolfi en realidad

Wolfi se describe como una distribución Linux sin kernel. Esa frase parece paradójica hasta que entiendes el contexto: una imagen de contenedor nunca ejecuta su propio kernel porque usa el del anfitrión. Todo el espacio dedicado a kernel, módulos e iniciadores en una distribución tradicional es, para un contenedor, peso muerto. Wolfi elimina esa capa y se queda solo con lo que ejecuta un proceso en espacio de usuario: glibc, gestor de paquetes, bibliotecas y binarios.

Lo distintivo frente a Alpine es la elección de glibc como biblioteca estándar. Alpine 3.24.1 usa musl 1.2.6, más compacta pero incompatible de formas sutiles con el software compilado para glibc. Esos casos de borde aparecen sobre todo en:

• Resolución DNS.

• Manejo de locales.

• Carga dinámica de módulos.

• Ruedas de Python que solo se publican para glibc (manylinux), como las de torch y onnxruntime.

Wolfi compila todo con glibc y recupera la compatibilidad con los binarios que funcionan en Debian o Ubuntu. El coste son unos megabytes: wolfi-base descarga 6,2 MB comprimidos frente a los 4,2 MB de alpine:3.24.1.

El gestor de paquetes es apk, el formato de Alpine, pero con repositorios propios que Chainguard construye y firma. Los paquetes de Wolfi no son los de Alpine con otro nombre: el README de wolfi-dev/os advierte de que no son compatibles entre sí y de que mezclarlos crea problemas de seguridad. Se compilan desde el código fuente y, desde noviembre de 2024, todos los paquetes C/C++ llevan las opciones de endurecimiento de OpenSSF (-fstack-protector-strong, -fcf-protection=full, -D_FORTIFY_SOURCE=3).

Desde la versión anterior de esta guía han cambiado dos cosas de gobierno. El repositorio público wolfi-dev/os es ahora una copia de solo lectura sincronizada desde repositorios internos de Chainguard, y sus pull requests no se fusionan directamente. Además, Wolfi solo incluye los paquetes necesarios para construir o ejecutar las imágenes gratuitas de Chainguard: cuando llegó MariaDB 12, los paquetes de MariaDB 11 pasaron al catálogo comercial de Chainguard OS. Las recetas siguen publicándose con licencia Apache 2.0.

Cómo probar wolfi-base en arm64

La imagen cgr.dev/chainguard/wolfi-base trae la base de Wolfi, apk y un shell de BusyBox, y arranca como root. Chainguard publica la misma imagen en Docker Hub como chainguard/wolfi-base. El 16 de septiembre de 2026 ambos registros servían el mismo índice, sha256:1d95114038f7…, creado a las 12:50 UTC.

docker run --rm -it cgr.dev/chainguard/wolfi-base

Dentro del contenedor, estas órdenes muestran la versión de apk, la de glibc, el repositorio configurado y cuántos paquetes trae la imagen:

$ grep VERSION_ID /etc/os-release
VERSION_ID="20230201"
$ apk --version
apk-tools 2.14.10, compiled for aarch64.
$ /usr/lib/libc.so.6 | head -1
GNU C Library (glibc-2.44-r6) stable release version 2.44.
$ cat /etc/apk/repositories
https://apk.cgr.dev/chainguard
$ apk info 2>/dev/null | wc -l
16

La imagen ocupa 15,6 MiB en disco y apunta a apk.cgr.dev/chainguard, no a packages.wolfi.dev/os como en la documentación de 2024. Chainguard sirve los ficheros de *.cgr.dev desde un almacenamiento de Cloudflare R2 (9236a389bd48b984df91adc1bc924620.r2.cloudflarestorage.com) que su guía de red pide permitir en el cortafuegos. En la red de esta prueba ese host devolvía un certificado autofirmado: apk add falló con certificate verify failed y descargué la imagen de Docker Hub.

Si te ocurre lo mismo, apunta apk a packages.wolfi.dev/os, que Chainguard documenta como repositorio de las imágenes gratuitas:

echo https://packages.wolfi.dev/os > /etc/apk/repositories
apk update
apk add curl | tail -3

fetch https://packages.wolfi.dev/os/aarch64/APKINDEX.tar.gz
 [https://packages.wolfi.dev/os]
OK: 106818 distinct packages available
(23/23) Installing curl (8.22.0-r2)
Executing busybox-1.38.0-r2.trigger
OK: 35 MiB in 39 packages

Para curl 8.22.0, apk instala 23 paquetes y la imagen pasa de 16 a 39 paquetes y 35 MiB.

Cómo buscar y listar paquetes de Wolfi

apk search consulta el índice que descarga apk update y es la vía que documenta Chainguard para saber qué publica Wolfi. El índice arm64 del 16 de septiembre tenía 106 818 compilaciones de 15 119 paquetes distintos, generados a partir de 4432 recetas. apk update cuenta cada versión por separado; apk search muestra solo la última de cada nombre:

$ apk search -q | wc -l
15119
$ apk search -e postgresql-18-client
postgresql-18-client-18.6-r2
$ apk search cmd:useradd
shadow-4.20.2-r1
$ apk search 'so:libxml2.so*'
libxml2-2.15.0-r0
libxml2-16-2.15.4-r0
libxml2-2.13-2-2.13.9-r0
$ apk search -v -e nginx
nginx-mainline-1.31.6-r0 - HTTP and reverse proxy server (mainline version)
nginx-stable-1.30.2-r0 - HTTP and reverse proxy server (stable version)
$ apk list -a nginx-stable | tail -3
nginx-stable-1.30.0-r1 aarch64 {nginx-stable} (BSD-2-Clause)
nginx-stable-1.30.1-r0 aarch64 {nginx-stable} (BSD-2-Clause)
nginx-stable-1.30.2-r0 aarch64 {nginx-stable} (BSD-2-Clause)

Cada forma de búsqueda resuelve una duda distinta:

• apk search -q: lista solo los nombres; con wc -l los cuentas
• -e nombre: coincidencia exacta con la última versión; -v añade la descripción
• cmd:orden: el paquete que instala un ejecutable (useradd viene en shadow)
• so:biblioteca: los paquetes que traen una biblioteca compartida
• apk list -a: todas las versiones que siguen en el repositorio, con su licencia

Los nombres no coinciden con los de Debian. No hay un paquete nginx, sino nginx-stable y nginx-mainline, y la versión mayor forma parte del nombre (postgresql-18-client, python-3.13). La receta de cada paquete es un YAML en el repositorio wolfi-dev/os de GitHub.

La publicación continua como decisión estructural

Las distribuciones tradicionales publican versiones numeradas. Debian 13 recibe revisiones puntuales (la 13.7 salió el 12 de septiembre de 2026). Ubuntu publica una versión cada seis meses y una LTS cada dos años, y Alpine abre una rama cada mayo y noviembre. Wolfi no tiene versiones numeradas: cada paquete se actualiza cuando sale una versión nueva del software original, y el repositorio está siempre al día.

Esta decisión tiene consecuencias en ambos sentidos:

• Ventaja: OpenSSL 3.6.4 se publicó en GitHub el 25 de agosto de 2026 a las 11:53 UTC. El índice arm64 de Wolfi registra libssl3 3.6.4-r0 compilado a las 13:25, y con OpenSSL 3.6.3, el 9 de junio, el margen fue de 9 h y 24 min. En las 24 h previas a mi prueba el índice sumó 751 compilaciones de 91 recetas.

• Desventaja: no hay puntos de referencia estables. El mismo Dockerfile puede producir otra imagen al día siguiente, y las versiones antiguas desaparecen. Desde el 13 de junio de 2026, Chainguard borra cada mes las versiones no actuales con más de 6 meses, salvo que otro paquete o una imagen de Chainguard las necesite.

Mi recomendación es anclar versiones cuando la reproducibilidad importe, con la sintaxis de apk: apk add curl=8.22.0-r2 para una versión exacta o apk add nginx-stable=~1.30 para una rama (las dos funcionaron en la prueba). Revisa esos anclajes antes de que cumplan 6 meses y, si necesitas versiones más antiguas, mantén tu propio espejo, como pide el aviso de Chainguard. Cuando lo que importe sea estar al día, acepta la publicación continua.

SBOM y firma como primeros principios

Cada paquete de Wolfi incluye su SBOM en formato SPDX, generado al compilar. En wolfi-base, /var/lib/db/sbom/ guarda 16 ficheros .spdx.json, uno por paquete instalado. Las imágenes de Chainguard añaden además un SBOM de imagen como atestación firmada, de modo que una imagen final trae el inventario de su contenido sin que tengas que generarlo tú.

La firma funciona en dos niveles. El índice APKINDEX.tar.gz lleva una firma RSA (.SIGN.RSA256.wolfi-signing.rsa.pub), que apk comprueba con las claves de /etc/apk/keys, y guarda el checksum de cada paquete. El .apk de zlib que descargué no traía segmento de firma propio: la confianza en cada paquete pasa por el índice, no por Sigstore.

Las imágenes sí se firman con cosign, desde el flujo de GitHub Actions de chainguard-images/images. Con cosign 3.1.3 la verificación queda así:

iss=https://token.actions.githubusercontent.com
repo=https://github.com/chainguard-images/images
id="$repo/.github/workflows/release.yaml@refs/heads/main"
args=(--certificate-oidc-issuer "$iss" --certificate-identity "$id")
img=cgr.dev/chainguard/wolfi-base
cosign verify "${args[@]}" "$img" > verify.json
echo $?

La orden devolvió 0 e informó de tres comprobaciones: las afirmaciones de cosign, su presencia en el registro de transparencia (verificada sin conexión) y el certificado de firma frente a las autoridades de confianza. El digest firmado era sha256:1d95114038f7…, el mismo que había descargado. El SBOM de la imagen se descarga como atestación:

spdx=https://spdx.dev/Document
opts=(--platform linux/arm64 --predicate-type "$spdx")
cosign download attestation "${opts[@]}" "$img" > att.json
jq -r .payload att.json | base64 -d > sbom.json
jq -r '.predicate.creationInfo.creators[]' sbom.json
jq '.predicate.packages | length' sbom.json

Tool: apko (v1.2.20)
Organization: Chainguard, Inc
80

Es un documento SPDX 2.3 con 80 entradas, que la propia cadena de Chainguard generó con apko 1.2.20. En mi caso, estos SBOM alimentan el escaneo de vulnerabilidades del pipeline. Con la base de datos del 16 de septiembre, Grype 0.118.0 dio 2 coincidencias en wolfi-base. Las dos están en zlib 1.3.2.1_rc20260601-r0: CVE-2026-85091 (alta) y GHSA-g5fp-32jq-cfw2.

El feed de seguridad de Wolfi (security.json), descargado esa misma noche, marca los dos identificadores como corregidos justo en esa versión. Contrasta cada hallazgo con el feed antes de abrir una incidencia. Para comparar escáneres tienes Trivy y Grype en el CI.

Cómo construir una imagen mínima con apko

apko construye imágenes a partir de paquetes apk y un fichero YAML, sin pasos RUN. Este curl.yaml crea una imagen sin shell que ejecuta curl con el usuario 65532:

contents:
  keyring:
    - https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
  repositories:
    - https://packages.wolfi.dev/os
  packages:
    - ca-certificates-bundle
    - curl
accounts:
  groups:
    - groupname: nonroot
      gid: 65532
  users:
    - username: nonroot
      uid: 65532
  run-as: nonroot
entrypoint:
  command: /usr/bin/curl
archs:
  - aarch64

Usé apko 1.4.1, publicado el 14 de septiembre de 2026, desde su imagen oficial (la copia de Docker Hub, con el mismo digest que en cgr.dev). Las opciones --user y HOME evitan que el contenedor escriba ficheros como root en tu directorio:

img=cgr.dev/chainguard/apko:latest
opts="--user $(id -u):$(id -g) -e HOME=/work -v $PWD:/work -w /work"
docker run --rm $opts $img build curl.yaml wolfi-curl:apko curl.tar
docker load < curl.tar
url=https://packages.wolfi.dev/os/wolfi-signing.rsa.pub
docker run --rm wolfi-curl:apko-arm64 -so /dev/null -w '%{http_code}' "$url"

La compilación tardó 4,9 s con una carga media de 22 en los 18 núcleos compartidos de la máquina. apko instaló 35 paquetes, dejó curl.tar (13 MB) junto a dos SBOM SPDX, y la imagen respondió 200. Si intentas abrir un shell, Docker responde stat /bin/sh: no such file or directory. Tres compilaciones entre las 21:52 y las 22:04 UTC produjeron la misma capa, sha256:fb0b508d….

Para congelar versiones, apko lock curl.yaml escribe curl.lock.json con el checksum de cada paquete y apko build --lockfile curl.lock.json lo respeta. Con el lockfile la capa cambió de digest (el orden de instalación es otro), pero se mantuvo estable entre ejecuciones.

melange, la herramienta que compila los paquetes, no pudo ejecutarse aquí. Su guía oficial la lanza con docker run --privileged, y la prueba mostró el motivo: melange 0.60.0 aísla cada compilación con bubblewrap y, sin ese modo, se detuvo con bwrap: Creating new namespace failed: Operation not permitted. No lancé contenedores privilegiados en una máquina compartida con otros procesos, así que esta guía no cubre la compilación de paquetes propios.

Comparativa práctica con Alpine y Debian slim

Para un binario Go estático la base apenas pesa, y Alpine sigue siendo la más pequeña. La diferencia aparece con una aplicación Python con bibliotecas compiladas. numpy 2.5.3, pandas 3.0.5 y pyarrow 25.0.1 ya publican ruedas musllinux, así que en Alpine se instalan sin compilar. torch 2.14.0 y onnxruntime 1.30.0 solo publican ruedas manylinux, que exigen glibc, y en Wolfi pip las encuentra:

$ apk add -q python-3.13 py3.13-pip
$ python3 -m venv /tmp/v && . /tmp/v/bin/activate
$ python --version
Python 3.13.15+
$ pip download -q --only-binary=:all: --no-deps -d /tmp/w onnxruntime torch
$ ls /tmp/w
onnxruntime-1.30.0-cp313-cp313-manylinux_2_28_aarch64.whl
torch-2.14.0-cp313-cp313-manylinux_2_28_aarch64.whl

La misma descarga de onnxruntime en alpine:3.24.1, con Python 3.14.7, termina con No matching distribution found for onnxruntime. numpy, en cambio, baja allí su rueda musllinux_1_2_aarch64.

Estas son las cifras de las tres bases, medidas el 16 de septiembre de 2026 en arm64:

Donde Wolfi gana claramente es en el ritmo de publicación y en el SBOM, no en el tamaño puro. La imagen de Debian que servía Docker Hub seguía en 13.6 cuatro días después de salir la 13.7, y 48 de sus 189 coincidencias ya tenían corrección publicada. En Alpine, 20 de las 23 la tenían.

El precio de adoptar Wolfi es la familiaridad del equipo con apk; esa fricción desaparece en un mes, pero existe. Si el escaneo de vulnerabilidades es la pieza que más te preocupa, ya escribí sobre cómo encaja esto con Docker Scout, que consume justamente estos SBOM a lo largo del pipeline de build.

Qué imágenes de Chainguard son gratuitas en 2026

Las imágenes gratuitas de Chainguard (Free Containers) se descargan sin cuenta, pero solo en su última compilación, con las etiquetas latest y latest-dev. En el registro, wolfi-base solo tenía la etiqueta latest. Desde el 16 de agosto de 2023, las etiquetas de versión son exclusivas de los planes de pago, aunque descargar por digest sigue abierto a todos. El manifiesto de un digest de wolfi-base del 5 de septiembre de 2025 seguía resolviéndose sin credenciales.

Desde el 17 de marzo de 2026, Catalog Starter permite elegir cinco imágenes del catálogo, con todas sus versiones soportadas, con una cuenta gratuita. Las imágenes de pago (Production) añaden etiquetas de versión, plazos de parcheo garantizados (SLA) y variantes FIPS; tienes el contexto en Chainguard Images: imágenes mínimas y firmadas. Con la capa gratuita, fija el digest en el Dockerfile (cgr.dev/chainguard/wolfi-base@sha256:…) y actualízalo en cada reconstrucción.

Dónde no encaja

Wolfi no encaja bien en dos casos:

• Aplicaciones con dependencias de paquetes Debian no portados. Cuando el sistema depende de un paquete específico de Ubuntu que Wolfi no empaqueta, reimportarlo desde código fuente es trabajo serio. Wolfi solo empaqueta lo que necesitan las imágenes gratuitas de Chainguard. También retira paquetes cuando su software llega al final de su vida, así que obliga a un inventario que a veces no compensa.

• Equipos sin capacidad de mantener imágenes propias. Wolfi gana cuando reconstruyes imágenes con regularidad y mantienes tu propio registro. Si el equipo depende de descargar una imagen pública, no ganas nada especial frente a una imagen oficial de Docker Hub bien elegida. El valor de Wolfi se manifiesta en el pipeline, no en el docker pull.

  Lo mismo aplica si tu runtime real es Podman sin daemon: la base cambia, pero la decisión sigue siendo la misma.

Cuándo compensa

La decisión de adoptar Wolfi depende de tu postura sobre cadena de suministro:

• Entornos regulados (cliente o auditor pide trazabilidad de cada binario): Wolfi ahorra trabajo desde el primer proyecto. El SBOM viene de serie, las firmas se verifican con una orden, el ritmo de publicación reduce la ventana de exposición y glibc evita los casos de borde de musl.

• Equipos pragmáticos (cadena no auditada, imágenes que se actualizan cada pocos meses): Wolfi no cambia la postura de seguridad de forma notable. La inversión en migrar Dockerfiles, formar al equipo en apk y vigilar la retención de 6 meses no se recupera. Debian slim reconstruido con regularidad ofrece un balance razonable.

El punto medio donde yo me he quedado es usar Wolfi como base para servicios que publican imágenes hacia fuera o manejan datos sensibles. Mantengo Debian slim para servicios internos donde la cadena de suministro no es un vector crítico. A medida que el equipo gana familiaridad, la frontera se mueve hacia más adopción como consolidación gradual, no como salto disruptivo.

Conclusión

Wolfi resuelve bien el triángulo glibc + SBOM nativo + parches rápidos que las distribuciones tradicionales no podían resolver juntos. En 2026 conviene sumar dos condiciones: las versiones antiguas duran 6 meses y la capa gratuita de Chainguard solo publica latest. No es la elección correcta para todo equipo, pero para quienes tienen presión de cumplimiento o pipelines de reconstrucción nocturna, reduce trabajo real. La adopción incremental, empezando por los servicios más expuestos, es el camino más sensato.

Este artículo también está disponible en inglés: Wolfi: the base distribution designed for containers.

Fuentes:

1. Chainguard: «Introducing Wolfi: The first Linux (un)distro designed for securing the software supply chain»^[1]
2. Repositorio oficial de paquetes de Wolfi en GitHub (wolfi-dev/os)^[2]
3. Wolfi en GitHub: descripción de la organización y FAQ^[3]
4. Chainguard Academy: documentación de referencia de Wolfi^[4]
5. Chainguard Academy: preguntas frecuentes de Wolfi^[5]
6. Chainguard Academy: selección de versiones de paquetes^[6]
7. Wolfi: la retención de versiones antiguas baja a 6 meses^[7]
8. Feed de seguridad de Wolfi (security.json)^[8]
9. Chainguard Academy: requisitos de red de Chainguard Containers^[9]
10. Chainguard Academy: verificar firmas y atestaciones con cosign^[10]
11. Chainguard Academy: categorías de imágenes, incluidas las gratuitas^[11]
12. Chainguard: cambios para los usuarios del catálogo público (2023)^[12]
13. Chainguard: «Introducing Chainguard Catalog Starter»^[13]
14. Chainguard: opciones de compilación endurecidas en Wolfi^[14]
15. Chainguard Academy: primeros pasos con apko^[15]
16. apko v1.4.1 en GitHub^[16]
17. Chainguard Academy: primeros pasos con melange^[17]
18. melange v0.60.0 en GitHub^[18]
19. Grype v0.118.0 en GitHub^[19]
20. cosign v3.1.3 en GitHub^[20]
21. OpenSSL 3.6.4 en GitHub^[21]
22. PyPI: torch^[22]
23. PyPI: metadatos de onnxruntime^[23]
24. Debian: versiones publicadas^[24]
25. Alpine Linux: calendario de versiones^[25]
26. Ubuntu: ciclo de versiones^[26]
27. SecurityWeek: «New ‘Wolfi’ Linux Distro Focuses on Software Supply Chain Security»^[27]

Preguntas frecuentes

¿Cómo busco y listo los paquetes disponibles en Wolfi?

Con apk search dentro de un contenedor wolfi-base, tras apk update: el 16 de septiembre de 2026, apk search -q | wc -l devolvió 15 119 paquetes. Los prefijos cmd: y so: buscan por orden y por biblioteca compartida, -e da la última versión de un nombre y apk list -a enseña todas las que quedan en el repositorio. Si apk.cgr.dev/chainguard no responde en tu red, pon https://packages.wolfi.dev/os en /etc/apk/repositories.

¿Puedo usar numpy o pandas en una imagen Wolfi sin compilar desde código fuente?

Sí: Wolfi compila todo con glibc 2.44, así que pip acepta las mismas ruedas manylinux que en Debian o Ubuntu. En Alpine la situación ha mejorado, porque numpy 2.5.3, pandas 3.0.5 y pyarrow 25.0.1 ya publican ruedas musllinux. La diferencia está en torch 2.14.0 u onnxruntime 1.30.0, que solo publican ruedas para glibc: en Wolfi pip las descargó y en Alpine 3.24.1 respondió No matching distribution found for onnxruntime. El coste de glibc son unos megabytes: 6,2 MB comprimidos frente a 4,2 MB.

¿Cómo consigo builds reproducibles si Wolfi no tiene versiones congeladas?

Anclando versiones cuando la reproducibilidad importe: apk add curl=8.22.0-r2 fija una versión exacta, apk add nginx-stable=~1.30 fija una rama y apko lock escribe un lockfile con el checksum de cada paquete. Desde el 13 de junio de 2026, Chainguard borra cada mes las versiones no actuales con más de 6 meses. Un ancla vieja acabará fallando si no mantienes un espejo propio. La contrapartida es la ventaja: el paquete arm64 de OpenSSL 3.6.4 llegó 1 h y 32 min después de la versión original, y las imágenes reconstruidas lo incorporan de inmediato.

¿Compensa Wolfi si mi equipo solo hace docker pull de imágenes públicas?

No especialmente: el valor de Wolfi se manifiesta en el pipeline, cuando reconstruyes imágenes con regularidad y mantienes tu propio registro. Además, la capa gratuita de Chainguard solo publica la última compilación (latest), y para fijar una versión tendrás que usar el digest, un plan de pago o Catalog Starter, con cinco imágenes a elegir. Tampoco encaja si dependes de paquetes Debian que Wolfi no empaqueta. Para equipos pragmáticos sin auditoría de la cadena de suministro, Debian slim reconstruido con regularidad ofrece un balance razonable sin coste de adopción.

Fuentes

1. Chainguard: «Introducing Wolfi: The first Linux (un)distro designed for securing the software supply chain»
2. Repositorio oficial de paquetes de Wolfi en GitHub (wolfi-dev/os)
3. Wolfi en GitHub: descripción de la organización y FAQ
4. Chainguard Academy: documentación de referencia de Wolfi
5. Chainguard Academy: preguntas frecuentes de Wolfi
6. Chainguard Academy: selección de versiones de paquetes
7. Wolfi: la retención de versiones antiguas baja a 6 meses
8. Feed de seguridad de Wolfi (security.json)
9. Chainguard Academy: requisitos de red de Chainguard Containers
10. Chainguard Academy: verificar firmas y atestaciones con cosign
11. Chainguard Academy: categorías de imágenes, incluidas las gratuitas
12. Chainguard: cambios para los usuarios del catálogo público (2023)
13. Chainguard: «Introducing Chainguard Catalog Starter»
14. Chainguard: opciones de compilación endurecidas en Wolfi
15. Chainguard Academy: primeros pasos con apko
16. apko v1.4.1 en GitHub
17. Chainguard Academy: primeros pasos con melange
18. melange v0.60.0 en GitHub
19. Grype v0.118.0 en GitHub
20. cosign v3.1.3 en GitHub
21. OpenSSL 3.6.4 en GitHub
22. PyPI: torch
23. PyPI: metadatos de onnxruntime
24. Debian: versiones publicadas
25. Alpine Linux: calendario de versiones
26. Ubuntu: ciclo de versiones
27. SecurityWeek: «New ‘Wolfi’ Linux Distro Focuses on Software Supply Chain Security»