dockerls 1.0.0__tar.gz → 1.0.2__tar.gz

{dockerls-1.0.0 → dockerls-1.0.2}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: dockerls
-Version: 1.0.0
+Version: 1.0.2
 Summary: Enterprise Docker Image Security Advisor
 Author: Ivomsantiago
 License: MIT
@@ -253,6 +253,11 @@ preciso". `base-image` faz essa escolha acontecer antes de qualquer coisa
 existir: sem `--with`, ele mostra um menu com o custo de cada pacote em
 superfície de ataque, não só o que ele serve.
 
+![menu de pacotes do base-image](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/base_image_menu.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ dockerls base-image --os alpine --runtime node
 
@@ -288,6 +293,8 @@ processes
 Comma-separated numbers (empty = no packages): 1,2,9
 ```
 
+</details>
+
 Repare no `curl`: o propósito ("HEALTHCHECK e diagnóstico de rede") é
 legítimo, mas o custo dito ali do lado é o mesmo que um atacante usa pra
 buscar o segundo estágio de um ataque. O menu não esconde isso pra depois —
@@ -296,6 +303,11 @@ mostra na hora de marcar.
 Em pipeline não tem menu pra responder. `--with` aceita a mesma lista
 separada por vírgula e pula direto pro Dockerfile:
 
+![base-image com --with, gerando o Dockerfile](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/base_image_with.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ dockerls base-image --os alpine --runtime node \
     --with "ca-certificates,tzdata,tini" -o Dockerfile \
@@ -311,6 +323,8 @@ Next step
 until then it is only an intention.
 ```
 
+</details>
+
 Existem três pacotes que esse catálogo se recusa a oferecer, mesmo por
 `--with` — são recusas documentadas, não omissões:
 
@@ -330,6 +344,11 @@ travada no catálogo (`RUNTIME_BASES`, em
 pra cada um. Se você precisa de outra versão, o caminho é editar a linha
 `FROM` manualmente e resolver o digest de novo:
 
+![dockerls base . repinando o digest](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/base_pin_digest.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ sed -i 's/FROM node:22-alpine@\${BASE_DIGEST}/FROM node:20-alpine/; s/ARG BASE_DIGEST=.*/ARG BASE_DIGEST=/' Dockerfile
 $ dockerls base .
@@ -351,6 +370,8 @@ Rebuild and scan before publishing: changing the base digest changes the image,
 and only a scan tells you whether for the better.
 ```
 
+</details>
+
 `base` não sabe (nem tenta adivinhar) se a troca de versão é segura — ele só
 garante que, seja qual for a tag, ela fica pinada por digest antes de ir pra
 frente. A resposta sobre segurança vem do scan, no passo 5.
@@ -366,6 +387,11 @@ do PowerShell inteiro a partir dali.
 
 ### 4. Validar antes de construir
 
+![resultado do analyze-dockerfile](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/analyze_dockerfile.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ dockerls analyze-dockerfile .
 
@@ -393,6 +419,8 @@ Summary: 9 passed | 4 warnings | 0 errors
 Security Score: 90/100   Tier: A   Production Ready: Yes
 ```
 
+</details>
+
 Isso roda sem Docker, sem scanner, sem rede — é análise estática do texto do
 Dockerfile. Os warnings aqui (sem multi-stage, sem HEALTHCHECK, sem
 `.dockerignore`) são exatamente o que aparece de novo como sugestão depois do
@@ -408,6 +436,11 @@ findings (base vs. suas camadas). `--fail-on critical,kev` soma mais um
 critério: falhar também se algum CVE encontrado está no catálogo CISA KEV —
 sendo explorado ativamente, mesmo que não seja CRITICAL.
 
+![dockerls build --production com o gate de segurança](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/build_production.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ dockerls build . -t minhaapp:1.0 --production --fail-on critical,kev `
     --owner "team-x" `
@@ -455,6 +488,8 @@ OUTPUT (measured after the build)
   Image       sha256:5e5a079bbd616d166b155f15dac48c9c603a9d605876c732fde620a7aa7958bc
 ```
 
+</details>
+
 Sem `--owner`, `--source` e `--security-contact`, esse mesmo comando falha —
 de propósito: `required_labels` é parte do perfil `--production`, e o motivo
 está no próprio erro quando isso acontece: "sem isso ninguém sabe pra quem
@@ -462,17 +497,29 @@ ligar quando essa imagem aparecer num alerta às três da manhã".
 
 ### 6. Usando a imagem depois de construída
 
+![docker run --rm minhaapp:1.0 id](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/docker_run_id.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ docker run --rm minhaapp:1.0 id
 uid=1000(node) gid=1000(node) groups=1000(node),1000(node)
 ```
 
+</details>
+
 `uid=1000`, não `uid=0`. É o `USER node` do Dockerfile confirmado em
 execução, não só lido no texto — a mesma checagem que `non_root_user` faz de
 forma estática no passo 4, agora contra o container de verdade.
 
 ### 7. Fechando o loop
 
+![dockerls analyze minhaapp:1.0 (imagem já construída)](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/analyze_final.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ dockerls analyze minhaapp:1.0
 
@@ -492,6 +539,8 @@ Analysis: minhaapp:1.0
   Scanner              trivy
 ```
 
+</details>
+
 O mesmo `analyze` que você rodaria contra `node:22-alpine` pra decidir se
 confia nela funciona igual contra o que você acabou de construir. Não existe
 um comando separado pra "auditar a própria imagem" — é o mesmo raio-x, na

{dockerls-1.0.0 → dockerls-1.0.2}/README.md

@@ -202,6 +202,11 @@ preciso". `base-image` faz essa escolha acontecer antes de qualquer coisa
 existir: sem `--with`, ele mostra um menu com o custo de cada pacote em
 superfície de ataque, não só o que ele serve.
 
+![menu de pacotes do base-image](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/base_image_menu.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ dockerls base-image --os alpine --runtime node
 
@@ -237,6 +242,8 @@ processes
 Comma-separated numbers (empty = no packages): 1,2,9
 ```
 
+</details>
+
 Repare no `curl`: o propósito ("HEALTHCHECK e diagnóstico de rede") é
 legítimo, mas o custo dito ali do lado é o mesmo que um atacante usa pra
 buscar o segundo estágio de um ataque. O menu não esconde isso pra depois —
@@ -245,6 +252,11 @@ mostra na hora de marcar.
 Em pipeline não tem menu pra responder. `--with` aceita a mesma lista
 separada por vírgula e pula direto pro Dockerfile:
 
+![base-image com --with, gerando o Dockerfile](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/base_image_with.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ dockerls base-image --os alpine --runtime node \
     --with "ca-certificates,tzdata,tini" -o Dockerfile \
@@ -260,6 +272,8 @@ Next step
 until then it is only an intention.
 ```
 
+</details>
+
 Existem três pacotes que esse catálogo se recusa a oferecer, mesmo por
 `--with` — são recusas documentadas, não omissões:
 
@@ -279,6 +293,11 @@ travada no catálogo (`RUNTIME_BASES`, em
 pra cada um. Se você precisa de outra versão, o caminho é editar a linha
 `FROM` manualmente e resolver o digest de novo:
 
+![dockerls base . repinando o digest](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/base_pin_digest.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ sed -i 's/FROM node:22-alpine@\${BASE_DIGEST}/FROM node:20-alpine/; s/ARG BASE_DIGEST=.*/ARG BASE_DIGEST=/' Dockerfile
 $ dockerls base .
@@ -300,6 +319,8 @@ Rebuild and scan before publishing: changing the base digest changes the image,
 and only a scan tells you whether for the better.
 ```
 
+</details>
+
 `base` não sabe (nem tenta adivinhar) se a troca de versão é segura — ele só
 garante que, seja qual for a tag, ela fica pinada por digest antes de ir pra
 frente. A resposta sobre segurança vem do scan, no passo 5.
@@ -315,6 +336,11 @@ do PowerShell inteiro a partir dali.
 
 ### 4. Validar antes de construir
 
+![resultado do analyze-dockerfile](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/analyze_dockerfile.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ dockerls analyze-dockerfile .
 
@@ -342,6 +368,8 @@ Summary: 9 passed | 4 warnings | 0 errors
 Security Score: 90/100   Tier: A   Production Ready: Yes
 ```
 
+</details>
+
 Isso roda sem Docker, sem scanner, sem rede — é análise estática do texto do
 Dockerfile. Os warnings aqui (sem multi-stage, sem HEALTHCHECK, sem
 `.dockerignore`) são exatamente o que aparece de novo como sugestão depois do
@@ -357,6 +385,11 @@ findings (base vs. suas camadas). `--fail-on critical,kev` soma mais um
 critério: falhar também se algum CVE encontrado está no catálogo CISA KEV —
 sendo explorado ativamente, mesmo que não seja CRITICAL.
 
+![dockerls build --production com o gate de segurança](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/build_production.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ dockerls build . -t minhaapp:1.0 --production --fail-on critical,kev `
     --owner "team-x" `
@@ -404,6 +437,8 @@ OUTPUT (measured after the build)
   Image       sha256:5e5a079bbd616d166b155f15dac48c9c603a9d605876c732fde620a7aa7958bc
 ```
 
+</details>
+
 Sem `--owner`, `--source` e `--security-contact`, esse mesmo comando falha —
 de propósito: `required_labels` é parte do perfil `--production`, e o motivo
 está no próprio erro quando isso acontece: "sem isso ninguém sabe pra quem
@@ -411,17 +446,29 @@ ligar quando essa imagem aparecer num alerta às três da manhã".
 
 ### 6. Usando a imagem depois de construída
 
+![docker run --rm minhaapp:1.0 id](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/docker_run_id.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ docker run --rm minhaapp:1.0 id
 uid=1000(node) gid=1000(node) groups=1000(node),1000(node)
 ```
 
+</details>
+
 `uid=1000`, não `uid=0`. É o `USER node` do Dockerfile confirmado em
 execução, não só lido no texto — a mesma checagem que `non_root_user` faz de
 forma estática no passo 4, agora contra o container de verdade.
 
 ### 7. Fechando o loop
 
+![dockerls analyze minhaapp:1.0 (imagem já construída)](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/analyze_final.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ dockerls analyze minhaapp:1.0
 
@@ -441,6 +488,8 @@ Analysis: minhaapp:1.0
   Scanner              trivy
 ```
 
+</details>
+
 O mesmo `analyze` que você rodaria contra `node:22-alpine` pra decidir se
 confia nela funciona igual contra o que você acabou de construir. Não existe
 um comando separado pra "auditar a própria imagem" — é o mesmo raio-x, na

{dockerls-1.0.0 → dockerls-1.0.2}/dockerls.egg-info/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: dockerls
-Version: 1.0.0
+Version: 1.0.2
 Summary: Enterprise Docker Image Security Advisor
 Author: Ivomsantiago
 License: MIT
@@ -253,6 +253,11 @@ preciso". `base-image` faz essa escolha acontecer antes de qualquer coisa
 existir: sem `--with`, ele mostra um menu com o custo de cada pacote em
 superfície de ataque, não só o que ele serve.
 
+![menu de pacotes do base-image](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/base_image_menu.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ dockerls base-image --os alpine --runtime node
 
@@ -288,6 +293,8 @@ processes
 Comma-separated numbers (empty = no packages): 1,2,9
 ```
 
+</details>
+
 Repare no `curl`: o propósito ("HEALTHCHECK e diagnóstico de rede") é
 legítimo, mas o custo dito ali do lado é o mesmo que um atacante usa pra
 buscar o segundo estágio de um ataque. O menu não esconde isso pra depois —
@@ -296,6 +303,11 @@ mostra na hora de marcar.
 Em pipeline não tem menu pra responder. `--with` aceita a mesma lista
 separada por vírgula e pula direto pro Dockerfile:
 
+![base-image com --with, gerando o Dockerfile](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/base_image_with.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ dockerls base-image --os alpine --runtime node \
     --with "ca-certificates,tzdata,tini" -o Dockerfile \
@@ -311,6 +323,8 @@ Next step
 until then it is only an intention.
 ```
 
+</details>
+
 Existem três pacotes que esse catálogo se recusa a oferecer, mesmo por
 `--with` — são recusas documentadas, não omissões:
 
@@ -330,6 +344,11 @@ travada no catálogo (`RUNTIME_BASES`, em
 pra cada um. Se você precisa de outra versão, o caminho é editar a linha
 `FROM` manualmente e resolver o digest de novo:
 
+![dockerls base . repinando o digest](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/base_pin_digest.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ sed -i 's/FROM node:22-alpine@\${BASE_DIGEST}/FROM node:20-alpine/; s/ARG BASE_DIGEST=.*/ARG BASE_DIGEST=/' Dockerfile
 $ dockerls base .
@@ -351,6 +370,8 @@ Rebuild and scan before publishing: changing the base digest changes the image,
 and only a scan tells you whether for the better.
 ```
 
+</details>
+
 `base` não sabe (nem tenta adivinhar) se a troca de versão é segura — ele só
 garante que, seja qual for a tag, ela fica pinada por digest antes de ir pra
 frente. A resposta sobre segurança vem do scan, no passo 5.
@@ -366,6 +387,11 @@ do PowerShell inteiro a partir dali.
 
 ### 4. Validar antes de construir
 
+![resultado do analyze-dockerfile](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/analyze_dockerfile.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ dockerls analyze-dockerfile .
 
@@ -393,6 +419,8 @@ Summary: 9 passed | 4 warnings | 0 errors
 Security Score: 90/100   Tier: A   Production Ready: Yes
 ```
 
+</details>
+
 Isso roda sem Docker, sem scanner, sem rede — é análise estática do texto do
 Dockerfile. Os warnings aqui (sem multi-stage, sem HEALTHCHECK, sem
 `.dockerignore`) são exatamente o que aparece de novo como sugestão depois do
@@ -408,6 +436,11 @@ findings (base vs. suas camadas). `--fail-on critical,kev` soma mais um
 critério: falhar também se algum CVE encontrado está no catálogo CISA KEV —
 sendo explorado ativamente, mesmo que não seja CRITICAL.
 
+![dockerls build --production com o gate de segurança](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/build_production.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ dockerls build . -t minhaapp:1.0 --production --fail-on critical,kev `
     --owner "team-x" `
@@ -455,6 +488,8 @@ OUTPUT (measured after the build)
   Image       sha256:5e5a079bbd616d166b155f15dac48c9c603a9d605876c732fde620a7aa7958bc
 ```
 
+</details>
+
 Sem `--owner`, `--source` e `--security-contact`, esse mesmo comando falha —
 de propósito: `required_labels` é parte do perfil `--production`, e o motivo
 está no próprio erro quando isso acontece: "sem isso ninguém sabe pra quem
@@ -462,17 +497,29 @@ ligar quando essa imagem aparecer num alerta às três da manhã".
 
 ### 6. Usando a imagem depois de construída
 
+![docker run --rm minhaapp:1.0 id](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/docker_run_id.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ docker run --rm minhaapp:1.0 id
 uid=1000(node) gid=1000(node) groups=1000(node),1000(node)
 ```
 
+</details>
+
 `uid=1000`, não `uid=0`. É o `USER node` do Dockerfile confirmado em
 execução, não só lido no texto — a mesma checagem que `non_root_user` faz de
 forma estática no passo 4, agora contra o container de verdade.
 
 ### 7. Fechando o loop
 
+![dockerls analyze minhaapp:1.0 (imagem já construída)](https://raw.githubusercontent.com/Ivomsantiago/DockerLs/Master/docs/assets/analyze_final.svg)
+
+<details>
+<summary>Ver como texto (copiar/colar)</summary>
+
 ```console
 $ dockerls analyze minhaapp:1.0
 
@@ -492,6 +539,8 @@ Analysis: minhaapp:1.0
   Scanner              trivy
 ```
 
+</details>
+
 O mesmo `analyze` que você rodaria contra `node:22-alpine` pra decidir se
 confia nela funciona igual contra o que você acabou de construir. Não existe
 um comando separado pra "auditar a própria imagem" — é o mesmo raio-x, na

{dockerls-1.0.0 → dockerls-1.0.2}/pyproject.toml

@@ -4,7 +4,7 @@ build-backend = "setuptools.build_meta"
 
 [project]
 name = "dockerls"
-version = "1.0.0"
+version = "1.0.2"
 description = "Enterprise Docker Image Security Advisor"
 readme = "README.md"
 license = {text = "MIT"}