2. Vulnerabilidade, exposição e risco em imagens

Em segurança computacional, uma vulnerabilidade pode ser entendida como uma fraqueza conhecida 
em pacote, biblioteca, configuração, aplicação ou componente de infraestrutura.

Entretanto, uma vulnerabilidade isolada não equivale automaticamente a risco assistencial. 
Para que exista risco relevante, é necessário compreender:
1.	se a vulnerabilidade é explorável;
2.	onde está localizada;
3.	se está em produção;
4.	se afeta dados sensíveis;
5.	se pode alterar uma decisão clínica;
6.	se há rastreabilidade;
7.	se existe mitigação implementada;
8.	se há impacto em:
•	confidencialidade;
•	integridade;
•	disponibilidade.

Na Medicina, essa distinção é fundamental. 
Uma biblioteca vulnerável em ambiente de teste pode ter baixo impacto imediato. 

A mesma biblioteca, em produção, dentro de um serviço que recebe tomografias para triagem
automatizada de AVC, pode adquirir criticidade assistencial.  Portanto, o risco deve ser lido por 
uma matriz ampliada:

|Elemento|Pergunta técnica|Pergunta médica|

|Vulnerabilidade|O pacote, imagem ou configuração tem falha conhecida?|	
|Essa falha pode atingir dado clínico ou conduta?|

|Exposição|A falha é acessível ou explorável?|O exame, laudo ou modelo está exposto?|

|Impacto|Afeta confidencialidade, integridade ou disponibilidade?|
|Pode atrasar diagnóstico, alterar conduta ou expor paciente?|

|Mitigação|Há patch, bloqueio, segmentação ou assinatura?|
|A continuidade assistencial foi preservada?|

3. A dupla superfície de ataque das imagens na Medicina com IA

A superfície de ataque em imagens médicas e computacionais pode ser organizada em 
duas dimensões.

# 3.1 Superfície de ataque da imagem médica
Inclui:
1.	aquisição da imagem no equipamento;
2.	identificação do paciente;
3.	metadados DICOM;
4.	armazenamento no PACS;
5.	exportação para CD, pen drive ou nuvem;
6.	envio por aplicativos de mensagem;
7.	anexação em prontuário;
8.	uso em pesquisa;
9.	treinamento de IA;
10.	compartilhamento em discussão clínica.


# 3.2 Superfície de ataque da imagem computacional
Inclui:
1.	Dockerfile;
2.	imagem base;
3.	bibliotecas Python;
4.	pacotes do sistema operacional;
5.	dependências de IA;
6.	secrets embutidos;
7.	registry;
8.	assinatura da imagem;
9.	políticas de admissão em Kubernetes;
10.	monitoramento em runtime.

A integração entre essas duas superfícies é o ponto mais sensível. 
•	Um exame de tomografia pode ser íntegro, mas ser processado por container vulnerável.

•	Um container pode estar assinado, mas receber imagem médica identificável por canal inseguro. 

•	Um modelo pode ser tecnicamente acurado, mas operar em ambiente sem logs, sem criptografia
e sem segregação.

4. Da imagem Docker à imagem médica: uma analogia necessária

Na engenharia de software, escanear uma imagem Docker significa verificar se o container contém: 
•	vulnerabilidades conhecidas, 
•	bibliotecas desatualizadas, 
•	pacotes inseguros, 
•	configurações frágeis,
•	componentes incompatíveis com o padrão de segurança esperado.

Na Medicina Assistida por IA, escanear o ecossistema de imagens médicas deveria significar algo mais amplo. 
Ele deve ser capaz de verificar se:
1.	a imagem contém dados identificáveis desnecessários;
2.	metadados sensíveis foram removidos ou preservados conforme finalidade;
3.	há autorização para uso assistencial, educacional ou científico;
4.	o armazenamento é privado;
5.	há criptografia;
6.	há logs de acesso;
7.	o pipeline de IA é seguro;
8.	o container que processa a imagem foi escaneado;
9.	a imagem computacional foi assinada;
10.	a decisão final permanece sob responsabilidade humana.

Assim, “varrer vulnerabilidades em imagens” na Medicina vai além do que escanear containers, 
ela significa instituir uma política de proteção da imagem como ativo clínico-computacional.

5. Shift Left Security aplicada à Medicina Assistida por IA

O conceito de Shift Left Security propõe inserir segurança desde as fases iniciais do desenvolvimento, 
e não apenas depois que o sistema está em produção.

Transposto para a Medicina com IA, isso significa que a segurança deve estar presente antes de:
1.	adquirir imagens médicas;
2.	montar dataset;
3.	treinar modelo;
4.	construir container;
5.	publicar imagem no registry;
6.	liberar endpoint de inferência;
7.	integrar com PACS;
8.	disponibilizar dashboard clínico;
9.	permitir uso assistencial;
10.	automatizar alertas.
A pergunta não deve ser apenas: “O modelo de IA funciona?”
Mas também: “O modelo foi construído, empacotado, publicado, executado e monitorado de modo seguro?”

6. SBOM, assinatura e rastreabilidade

O SBOM, ou Software Bill of Materials, funciona como uma lista de componentes de 
software. Em termos simples: 
•	Ele é uma espécie de “bula técnica” da imagem computacional. 
•	Ele permite saber quais bibliotecas, pacotes e versões estão presentes em uma imagem.

Na Medicina, essa ideia é extremamente poderosa. 
Se um container interpreta imagens radiológicas, o serviço de saúde deveria ser capaz de responder:
1.	qual imagem Docker está em produção?
2.	qual modelo de IA está dentro dela?
3.	quais bibliotecas foram usadas?
4.	qual versão do Python foi usada?
5.	há pacotes vulneráveis?
6.	quando foi o último scanner?
7.	a imagem está assinada?
8.	quem aprovou o deploy?
9.	há logs de inferência?
10.	houve impacto sobre decisão clínica?

Sem isso, o hospital pode usar IA sem conseguir explicar a infraestrutura que sustenta 
sua decisão computacional.

7. Matriz geral: vulnerabilidade, exposição, risco assistencial e mitigação

# |Vulnerabilidade|	Exposição|Risco assistencial|Mitigação proposta|

|1. Imagem médica com metadados identificáveis|Compartilhamento externo|
|Violação de privacidade e reidentificação|Anonimização, autorização, logs, política institucional|

|2. Bucket ou pasta em nuvem com imagens clínicas|Link público ou permissão ampla|
|Vazamento de exames e laudos|Bloqueio público, criptografia, IAM mínimo, auditoria|

|3. Container de IA com biblioteca vulnerável|Endpoint em produção|
|Indisponibilidade ou manipulação do serviço|Scanner, patch, rebuild, SBOM, assinatura|

|4. Imagem Docker sem assinatura|Deploy não rastreável|
|Execução de artefato adulterado|Cosign, policy admission, registry controlado|

|5. PACS sem segmentação adequada|Movimento lateral na rede|
|Ransomware, indisponibilidade, atraso diagnóstico|Segmentação, MFA, logs, hardening|

|6. Uso de WhatsApp pessoal para imagem clínica	|Ausência de governança|
|Exposição indevida e perda de rastreabilidade|Canal institucional, consentimento, política de uso|

|7. IA processando imagem sem supervisão|Automação excessiva|
|Erro diagnóstico ou falso negativo|Revisão médica, limiares, validação, registro|

|8. Dataset sem controle de origem|Treinamento enviesado ou contaminado|
|Modelo inseguro ou não generalizável|Data governance, versionamento, curadoria|

8. Caso Clínico-Computacional 1

# Tomografia de crânio compartilhada por link público em ambiente de nuvem

# 1. Contexto clínico
- Paciente atendido em pronto atendimento por cefaleia intensa e déficit neurológico focal. 
- Foi realizada tomografia de crânio sem contraste. A equipe deseja discutir rapidamente 
o caso com neurologista externo e envia a imagem por link de armazenamento em nuvem.
- O link foi criado como “qualquer pessoa com o link pode visualizar”. 
- O exame contém metadados com nome, data de nascimento, número de registro e data do exame.

# 2. Superfície de ataque
1.	link público;
2.	ausência de autenticação;
3.	ausência de expiração automática;
4.	metadados identificáveis;
5.	ausência de trilha de auditoria;
6.	possível download não rastreado;
7.	uso de canal não institucional.

# 3. Impacto clínico e legal
O risco principal é a violação de confidencialidade. Entretanto, há também risco assistencial indireto: 
se uma versão errada ou incompleta da imagem for compartilhada, a discussão clínica pode ocorrer 
com base em dado inadequado.

# 4. Código educacional: avaliação de compartilhamento seguro

def avaliar_compartilhamento_imagem(
    contem_identificacao: bool,
    link_publico: bool,
    possui_expiracao: bool,
    acesso_auditavel: bool,
    canal_institucional: bool,
    finalidade_definida: bool
):
    risco = 0
    alertas = []
    if contem_identificacao:
        risco += 3
        alertas.append("Imagem contém dados identificáveis.")
    if link_publico:
        risco += 4
        alertas.append("Link público detectado.")
    if not possui_expiracao:
        risco += 2
        alertas.append("Link sem expiração automática.")
    if not acesso_auditavel:
        risco += 2
        alertas.append("Acesso sem trilha de auditoria.")
    if not canal_institucional:
        risco += 3
        alertas.append("Canal não institucional utilizado.")
    if not finalidade_definida:
        risco += 2
        alertas.append("Finalidade clínica, educacional ou científica não definida.")
    if risco >= 10:
        classificacao = "RISCO CRÍTICO"
    elif risco >= 6:
        classificacao = "RISCO ALTO"
    elif risco >= 3:
        classificacao = "RISCO MODERADO"
    else:
        classificacao = "RISCO BAIXO"
    return {
        "classificacao": classificacao,
        "pontuacao": risco,
        "alertas": alertas,
        "acao_recomendada": "Não compartilhar até corrigir os pontos críticos."
        if risco >= 6 else "Compartilhamento aceitável com registro e finalidade definida."
    }
resultado = avaliar_compartilhamento_imagem(
    contem_identificacao=True,
    link_publico=True,
    possui_expiracao=False,
    acesso_auditavel=False,
    canal_institucional=False,
    finalidade_definida=True
)
print(resultado)

# 5. Saída esperada

{
  "classificacao": "RISCO CRÍTICO",
  "pontuacao": 14,
  "alertas": [
    "Imagem contém dados identificáveis.",
    "Link público detectado.",
    "Link sem expiração automática.",
    "Acesso sem trilha de auditoria.",
    "Canal não institucional utilizado."
  ],
  "acao_recomendada": "Não compartilhar até corrigir os pontos críticos."
}

6. Mitigação proposta
1.	remover ou anonimizar metadados identificáveis quando aplicável;
2.	usar canal institucional;
3.	restringir acesso por identidade;
4.	configurar expiração do link;
5.	registrar finalidade;
6.	manter log de acesso;
7.	documentar no prontuário quando houver impacto na conduta;
8.	evitar envio por aplicativo pessoal;
9.	garantir que a imagem discutida corresponde ao paciente correto;
10.	registrar a decisão médica final.

9. Caso Clínico-Computacional 2

# Container de IA para triagem radiológica com vulnerabilidade crítica

# 1. Contexto clínico
- Hospital implanta ferramenta de IA para apoiar triagem de radiografias de tórax em 
pronto atendimento. A aplicação recebe imagem, executa inferência e classifica risco de 
achados sugestivos de pneumotórax, consolidação ou derrame pleural.
- O modelo está empacotado em container Docker. 
- Durante scanner automatizado, é identificada vulnerabilidade crítica em biblioteca 
presente na imagem base.

# 2. Superfície de ataque
1.	imagem Docker desatualizada;
2.	dependências vulneráveis;
3.	ausência de SBOM;
4.	pipeline sem bloqueio automático;
5.	imagem não assinada;
6.	deploy direto em produção;
7.	ausência de monitoramento em runtime.

# 3. Impacto clínico
A vulnerabilidade pode não alterar diretamente o algoritmo, mas pode comprometer 
a disponibilidade ou integridade do serviço. 
Em cenário assistencial, indisponibilidade de triagem automatizada pode atrasar priorização. 
Comprometimento do container pode expor imagens, logs ou resultados de inferência.

# 4. Exemplo de Dockerfile inseguro
FROM python:3.9
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY . .
ENV API_KEY="chave_exemplo_nao_usar_em_producao"
CMD ["python", "app.py"]

# 5. Problemas didáticos identificados
1.	imagem base genérica;
2.	ausência de pinning rigoroso de versões;
3.	ausência de usuário não-root;
4.	segredo embutido no Dockerfile;
5.	ausência de etapa de verificação;
6.	ausência de SBOM;
7.	ausência de assinatura.

# 6. Exemplo de Dockerfile mais seguro
FROM python:3.11-slim
WORKDIR /app
RUN useradd -m appuser
COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt
COPY . .
USER appuser
CMD ["python", "app.py"]

# 7. Exemplo de pipeline com scanner Trivy
name: scan-medical-ai-image
on:
  push:
    branches:
      - main
jobs:
  scan-container:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout do repositório
        uses: actions/checkout@v4
      - name: Build da imagem
        run: docker build -t ia-radiologia:latest .
      - name: Varredura de vulnerabilidades com Trivy
        uses: aquasecurity/trivy-action@master
        with:
          image-ref: ia-radiologia:latest
          format: table
          exit-code: 1
          severity: CRITICAL,HIGH
      - name: Gerar SBOM
        run: |
          trivy image --format cyclonedx --output sbom-ia-radiologia.json ia-radiologia:latest

# 8. Interpretação clínica do pipeline
O ponto central não é transformar o médico em engenheiro DevSecOps. 
O ponto é permitir que a governança clínica pergunte:
1.	a imagem foi escaneada?
2.	houve vulnerabilidade crítica?
3.	quem autorizou o deploy?
4.	a vulnerabilidade afeta produção?
5.	existe plano de correção?
6.	há impacto sobre atendimento?
7.	o serviço precisa ser retirado temporariamente?
8.	há alternativa assistencial manual?
9.	os logs foram preservados?
10.	o risco foi comunicado?

# 9. JSON de registro de decisão
{
  "evento_segurança_ia": {
    "id_evento": "IMG-IA-SEC-2026-0002",
    "sistema": "triagem_radiologica_ia",
    "tipo_de_imagem": "container_docker",
    "scanner": "trivy",
    "severidade_maxima": "CRITICAL",
    "sbom_gerado": true,
    "imagem_assinada": false,
    "ambiente": "staging",
    "deploy_em_producao_autorizado": false,
    "risco_clinico": "indisponibilidade_potencial_do_servico",
    "acao": "bloquear_deploy_ate_rebuild_e_nova_varredura",
    "responsavel_tecnico": "equipe_devsecops",
    "responsavel_clinico": "lideranca_assistencial",
    "decisao_final": "não liberar para produção"
  }
}

10. Mitigação proposta
1.	atualizar imagem base;
2.	remover secrets do Dockerfile;
3.	gerar SBOM;
4.	aplicar scanner no CI/CD;
5.	bloquear deploy com vulnerabilidade crítica;
6.	assinar imagem aprovada;
7.	usar Admission Controller;
8.	monitorar runtime;
9.	manter fallback assistencial;
10.	registrar decisão técnica e clínica.

10. Caso Clínico-Computacional 3

# Arquivo DICOM com metadados sensíveis e risco de reidentificação em pesquisa com IA

# 1. Contexto clínico
- Equipe de pesquisa deseja treinar modelo de IA para identificar achados em exames de tomografia. 
- As imagens são exportadas do PACS para ambiente de pesquisa em nuvem.
- Apesar de os nomes dos arquivos terem sido trocados por códigos, os metadados DICOM ainda 
contêm identificadores indiretos: 
1. data de nascimento, 
2. data do exame, 
3. número de acesso, 
4. instituição, 
5. médico solicitante,
6. identificadores internos.

# 2. Superfície de ataque
1.	anonimização incompleta;
2.	metadados DICOM preservados indevidamente;
3.	risco de reidentificação;
4.	bucket de pesquisa com permissões amplas;
5.	ausência de trilha de auditoria;
6.	ausência de separação entre pesquisa e produção;
7.	uso posterior em treinamento de IA.

# 3. Impacto clínico, ético e regulatório
- Mesmo sem nome explícito, a combinação de dados pode permitir reidentificação. 
- Em pesquisa com IA, o risco aumenta porque datasets são copiados, versionados, 
transformados e reutilizados. 
- O problema deixa de ser apenas “vazamento de arquivo” e passa a envolver cadeia de 
dados, governança e responsabilidade institucional.

# 4.  Código educacional: inspeção de metadados DICOM

# Exemplo educacional.
# Não utilizar diretamente em produção sem validação institucional,
# jurídica, ética e técnica.

import pydicom

CAMPOS_SENSIVEIS = [
    "PatientName",
    "PatientID",
    "PatientBirthDate",
    "PatientSex",
    "AccessionNumber",
    "InstitutionName",
    "ReferringPhysicianName",
    "StudyDate",
    "StudyTime"
]
def inspecionar_dicom(caminho_arquivo):
    ds = pydicom.dcmread(caminho_arquivo, stop_before_pixels=True)
    achados = {}
    for campo in CAMPOS_SENSIVEIS:
        valor = getattr(ds, campo, None)
        if valor:
            achados[campo] = str(valor)
    if achados:
        status = "ATENÇÃO: metadados sensíveis encontrados."
    else:
        status = "OK: nenhum campo sensível listado foi encontrado."
    return {
        "arquivo": caminho_arquivo,
        "status": status,
        "campos_encontrados": achados
    }
resultado = inspecionar_dicom("exame_sintetico.dcm")
print(resultado)

# 5. Código educacional: anonimização básica de metadados

import pydicom

from datetime import datetime
def anonimizar_dicom(caminho_entrada, caminho_saida):
    ds = pydicom.dcmread(caminho_entrada)
    substituicoes = {
        "PatientName": "PACIENTE_ANONIMIZADO",
        "PatientID": "ID_ANONIMO",
        "PatientBirthDate": "",
        "AccessionNumber": "",
        "InstitutionName": "INSTITUICAO_REMOVIDA",
        "ReferringPhysicianName": "",
        "StudyDate": "",
        "StudyTime": ""
    }
    for campo, novo_valor in substituicoes.items():
        if hasattr(ds, campo):
            setattr(ds, campo, novo_valor)
    ds.remove_private_tags()
    ds.PatientIdentityRemoved = "YES"
    ds.DeidentificationMethod = "Remocao educacional de metadados sensiveis"
    ds.ContentDate = datetime.now().strftime("%Y%m%d")
    ds.save_as(caminho_saida)
    return {
        "entrada": caminho_entrada,
        "saida": caminho_saida,
        "status": "arquivo anonimizado para uso educacional"
    }
relatorio = anonimizar_dicom("exame_sintetico.dcm", "exame_anonimizado.dcm")
print(relatorio)


# 6. Código educacional: validação antes de envio para IA

def validar_envio_para_ia(
    metadados_sensiveis_presentes: bool,
    autorizacao_etica: bool,
    ambiente_privado: bool,
    logs_ativos: bool,
    finalidade: str,
    revisao_humana: bool
):
    bloqueios = []
    if metadados_sensiveis_presentes:
        bloqueios.append("Metadados sensíveis ainda presentes.")
    if not autorizacao_etica:
        bloqueios.append("Ausência de autorização ética ou institucional.")
    if not ambiente_privado:
        bloqueios.append("Ambiente de armazenamento não privado.")
    if not logs_ativos:
        bloqueios.append("Ausência de logs de acesso.")
    if not finalidade:
        bloqueios.append("Finalidade não definida.")
    if not revisao_humana:
        bloqueios.append("Ausência de revisão humana responsável.")
    if bloqueios:
        return {
            "status": "NÃO ENVIAR PARA IA",
            "bloqueios": bloqueios
        }
    return {
        "status": "ENVIO PERMITIDO COM GOVERNANÇA",
        "observacao": "Manter rastreabilidade, controle de acesso e documentação."
    }
decisao = validar_envio_para_ia(
    metadados_sensiveis_presentes=True,
    autorizacao_etica=True,
    ambiente_privado=True,
    logs_ativos=False,
    finalidade="pesquisa_aprovada",
    revisao_humana=True
)
print(decisao)

continuação:

6. Saída esperada

{
  "status": "NÃO ENVIAR PARA IA",
  "bloqueios": [
    "Metadados sensíveis ainda presentes.",
    "Ausência de logs de acesso."
  ]
}

# 7. Mitigação proposta
1.	anonimizar adequadamente;
2.	remover tags privadas;
3.	manter documentação da anonimização;
4.	separar ambiente de pesquisa e produção;
5.	controlar acesso por identidade;
6.	criptografar armazenamento;
7.	manter logs;
8.	impedir download indiscriminado;
9.	versionar datasets;
10.	submeter uso a governança ética e institucional.

11. Checklist prático para equipes de saúde

# 11.1 - Para médicos
|Pergunta|Justificativa|

|A imagem contém identificação do paciente?|Proteção de privacidade|

|A finalidade está definida?|Evita uso indevido|

|A ferramenta é institucional?|Reduz risco jurídico|

|A IA apenas apoia ou decide?|Preserva responsabilidade médica|

|O resultado será revisado?|Evita automação insegura|

|A conduta final será documentada?|Garante rastreabilidade|

# 11.2 - Para TI e Segurança da Informação

|Pergunta|Justificativa|

|O storage é privado?|Evita vazamento|

|Há criptografia?|Protege dado sensível|

|Há logs?|Permite auditoria|

|A imagem Docker foi escaneada?|Reduz vulnerabilidade técnica|

|Existe SBOM?|Permite rastrear dependências|

|A imagem foi assinada?|Reduz risco de adulteração|

|O deploy pode ser bloqueado?|Impede produção insegura|

# 11.3 - Para Engenharia Clínica
| Pergunta|Justificativa|

|O equipamento está inventariado?|Controla ativos|

|Há integração com PACS?|Define fluxo de imagem|

|Há segmentação de rede?|Reduz movimento lateral|

|Há política de atualização?|Reduz exposição|

|O fabricante participa da resposta?|Responsabilidade compartilhada|


# 11.4 - Para Governança e Compliance

|Pergunta|Justificativa|

|Existe política para imagens médicas?|Define padrão institucional|

|Há base legal ou autorização?|Conformidade regulatória|

|Há matriz de risco?|Priorização objetiva|

|Há plano de incidente?|Resposta organizada|

|Há treinamento multiprofissional?|Cultura de segurança|

12. Proposta de Health Score para imagens médicas e computacionais

A ideia de health score pode ser adaptada para avaliar a segurança do fluxo de imagens.

|Critério|Pontuação|

|Imagem médica sem identificação desnecessária|+3|

|Finalidade definida|+2|

|Canal institucional|+2|

|Storage privado|+3|

|Logs ativos|+2|

|Criptografia ativa|+2|

|Revisão humana documentada|+3|

|Container escaneado|+3|

|SBOM disponível|+2|

|Imagem computacional assinada|+3|

|Link público sem expiração|-5|

|Metadados sensíveis sem justificativa|-5|

|Container com vulnerabilidade crítica|-7|

|Deploy sem aprovação|-7|

|IA impactando conduta sem revisão médica|-10|

# Pseudocódigo

def calcular_health_score(controles):
    score = 0

    pesos = {
        "sem_identificacao_desnecessaria": 3,
        "finalidade_definida": 2,
        "canal_institucional": 2,
        "storage_privado": 3,
        "logs_ativos": 2,
        "criptografia": 2,
        "revisao_humana": 3,
        "container_escaneado": 3,
        "sbom_disponivel": 2,
        "imagem_assinada": 3,
        "link_publico_sem_expiracao": -5,
        "metadados_sensiveis_sem_justificativa": -5,
        "vulnerabilidade_critica": -7,
        "deploy_sem_aprovacao": -7,
        "ia_sem_revisao_medica": -10
    }
    for controle, presente in controles.items():
        if presente:
            score += pesos.get(controle, 0)
    if score >= 18:
        classificacao = "SAUDÁVEL"
    elif score >= 10:
        classificacao = "ACEITÁVEL COM MONITORAMENTO"
    elif score >= 1:
        classificacao = "FRÁGIL"
    else:
        classificacao = "CRÍTICO"
    return {
        "health_score": score,
        "classificacao": classificacao
    }
    
avaliacao = calcular_health_score({
    "sem_identificacao_desnecessaria": False,
    "finalidade_definida": True,
    "canal_institucional": False,
    "storage_privado": True,
    "logs_ativos": False,
    "criptografia": True,
    "revisao_humana": True,
    "container_escaneado": True,
    "sbom_disponivel": False,
    "imagem_assinada": False,
    "link_publico_sem_expiracao": True,
    "metadados_sensiveis_sem_justificativa": True,
    "vulnerabilidade_critica": False,
    "deploy_sem_aprovacao": False,
    "ia_sem_revisao_medica": False
})
print(avaliacao)

13. Discussão

A Medicina sempre valorizou imagem, evidência e interpretação. 

O que muda agora é que a imagem deixou de circular apenas no negatoscópio, 
no laudo ou no prontuário. Ela passou a circular em:
1.	pipelines, 
2.	APIs, 
3.	modelos, 
4.	clouds, 
5.	containers, 
6.	datasets, 
7.	dashboards,
8.	aplicações móveis.

Isso exige uma nova competência profissional: a alfabetização clínico-computacional 
em segurança de imagens.

O médico não precisa saber operar todas as ferramentas. Mas precisa saber perguntar:
1.	onde a imagem está armazenada?
2.	quem acessa?
3.	há log?
4.	há criptografia?
5.	há metadados sensíveis?
6.	há autorização?
7.	há IA envolvida?
8.	o container da IA foi escaneado?
9.	há SBOM?
10.	a decisão final foi humana?

A ausência dessas perguntas pode produzir falsa segurança. Um sistema pode parecer 
sofisticado, mas operar com: 
•	links públicos, 
•	containers vulneráveis, 
•	ausência de logs,
•	dados sensíveis desnecessários.

Na Medicina Assistida por IA, cibersegurança não é acessório. É parte da prudência clínica.

14. Limites

Este artigo tem finalidade educacional e conceitual. 

Os códigos apresentados são exemplos didáticos e não substituem validação técnica, jurídica, ética 
ou institucional. 

Ambientes reais de saúde exigem: 
1.	capacitação profissional constante,
2.	política da meritocracia,
3.	políticas formais, 
4.	governança de dados, 
5.	revisão de segurança, 
6.	tecnovigilância,
7.	análise de risco, 
8.	validação clínica, 
9.	controle de acesso, 
10.	conformidade regulatória,
11.	participação multiprofissional.

Além disso, anonimização de imagens médicas é tema complexo. 

A simples remoção de campos aparentes pode ser insuficiente em muitos contextos. 

Determinadas imagens podem conter identificadores:  
1.	no próprio pixel, 
2.	em metadados privados,
3.	em combinações indiretas de dados.

15. Considerações finais

A varredura de vulnerabilidades em imagens, quando transportada para a Medicina Assistida por IA, 
revela um campo extremamente relevante e ainda pouco discutido.

De um lado, há imagens computacionais, como: 
1.	containers, 
2.	bibliotecas, 
3.	pacotes, 
4.	dependências, 
5.	SBOM, 
6.	Assinatura,
7.	runtime. 

De outro, há imagens médicas, como: 
1.	DICOM, 
2.	PACS, 
3.	tomografias, 
4.	radiografias, 
5.	ultrassons, 
6.	fotografias clínicas,
7.	datasets de IA.

A segurança real nasce quando essas duas dimensões são tratadas como partes de uma 
mesma cadeia assistencial.
•	O exame precisa ser protegido.
•	O container precisa ser protegido.
•	O modelo precisa ser monitorado.
•	O acesso precisa ser auditável.
•	A decisão precisa permanecer humana.
•	A rastreabilidade precisa ser preservada.

Na Medicina contemporânea:
•	proteger imagens é proteger pacientes;

Na era da IA:
•	proteger pacientes exige compreender que a segurança do cuidado começa muito antes 
da decisão clínica: começa no modo como dados, códigos, containers, modelos e profissionais 
passam a interagir dentro de uma mesma arquitetura de responsabilidade.

Oi, Ricardo!

Que contribuição fantástica para o nosso fórum. É fascinante ver a segurança de infraestrutura (DevSecOps) aplicada diretamente no cenário real da Medicina Assistida por IA. O seu artigo demonstra com maestria como o conceito de "imagem" ganha esse duplo sentido tão vital na saúde digital.

O seu paralelo entre os dois significados de "imagem" deixa muito evidente que a cadeia de cuidado com o paciente agora passa pela segurança do servidor e do código. Destaco especialmente o exemplo prático do Caso 2: a transição para uma imagem base -slim, a configuração de um usuário sem privilégios administrativos (appuser) e a automação da varredura com o Trivy no pipeline de CI/CD são exatamente as práticas recomendadas para proteger a cadeia de suprimentos de software.

E, a sua proposta de Health Score unindo controles técnicos (como criptografia e varredura) a controles clínicos (como a revisão humana) serve como um excelente modelo de governança para hospitais e clínicas que começam a adotar algoritmos no dia a dia.

Parabéns pelo aprofundamento, pela didática com os códigos em Python e por compartilhar um material tão rico e interdisciplinar com a comunidade!

Olhando para essa matriz de risco que você montou, qual dessas mitigações você acredita ser o maior desafio de cultura e conscientização para as equipes de saúde aceitarem no dia a dia dos hospitais?

Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!

Olá, Lorena.
Durante as aulas relacionadas ao artigo, chamou-me muita atenção a absoluta falta de orientações sobre segurança
cibernética e conformidade com a legislação — especialmente a LGPD — no contexto do compartilhamento de imagens médicas.

Esse hábito, que se tornou um dos pilares da assistência médica moderna, envolve a troca de achados diagnósticos por meios virtuais
entre profissionais do mesmo serviço ou convidados pela sua especialização. No entanto, apesar de ser uma prática comum e muitas
vezes necessária, ela ocorre frequentemente sem criptografia, sem controle institucional e por dispositivos pessoais, majoritariamente
smartphones conectados a redes privadas e públicas vulneráveis ao acesso de invasores qualificados.

Essas discussões têm como objetivo identificar alterações patológicas, confirmar diagnósticos e definir condutas terapêuticas. Porém,
a forma como são realizadas hoje expõe profissionais, pacientes, hospitais e gestores a riscos elevados — justamente pela ausência de
políticas claras de segurança, treinamento adequado e governança.

Diante disso, e respondendo diretamente à sua pergunta, considero que dois pontos da matriz de mitigação merecem ampla
discussão e compor uma “política de segurança”, discutida inclusive ao longo do curso e no artigo.

6. Uso de WhatsApp pessoal para imagem clínica
   • Risco: exposição indevida e perda de rastreabilidade
   • Causa: ausência de governança
   • Mitigação: canal institucional, consentimento, política de uso

7. IA processando imagem sem supervisão
   • Risco: erro diagnóstico ou falso negativo
   • Causa: automação excessiva
   • Mitigação: revisão médica, definição de limiares, validação e registro

Agradeço novamente sua análise detalhada e reitero minha admiração pelo seu elevado grau de conhecimento também na área
médica.

Att.,

Ricardo