2. Definições essenciais

# 2.1	DMIA
Dispositivo Médico com Inteligência Artificial . É empregado como termo operacional 
para designar;

•	dispositivo médico físico, 

•	software embarcado, 

•	sistema híbrido,

•	conjunto médico

Deve utilizar técnicas de IA ou aprendizado de máquina em alguma função relevante, 
como:
1. detecção,
2. classificação, 
3. predição, 
4. priorização, 
5. recomendação, 
6. monitorização ,
7. controle. 

# 2.2 SaMD
Software as a Medical Device (SaMD) 
Destinado a uma ou mais finalidades médicas que executa essas finalidades sem fazer 
parte do hardware DM.  

# 2.3 Cadeia de suprimentos cibernética, que compreende:
1. atores, 

2. ativos, 

3. processos

4. relações utilizados para projetar, 

5. desenvolver, 

6. treinar,

7. fabricar, 

8. integrar,  

9. distribuir, 

10. atualizar, 

11. operar, 

12. manter e descontinuar um produto ou serviço digital. 

- Em saúde digital , ela deve incluir:

1. fornecedores diretos,

2. subcontratados, 

3. bibliotecas transitivas, 

4. serviços de hospedagem, 

5. registries, 

6. laboratórios, 

7. empresas de telecomunicação,

8. processadores de dados, 

9. provedores de identidade, 

10. integradores, 

11. empresas de manutenção,

12. plataformas de IA.

# 2.4 C-SCRM
Cybersecurity Supply Chain Risk Management (C-SCRM) é a aplicação sistemática 
de:
1. governança, 
2. avaliação de risco,
3. requisitos de aquisição, 
4. verificação técnica,
5. monitoramento,
6. resposta para reduzir ameaças originadas ou propagadas pela cadeia. 

Não é um questionário anual isolado, mas sim um processo contínuo, proporcional à criticidade 
clínica e capaz de acompanhar mudanças de versão, propriedade, subcontratação, arquitetura e
exposição.

# 2.5 SBOM, VEX, AI-BOM e proveniência
|Elemento|Definição prática|Valor clínico-operacional|

|1- SBOM|Inventário estruturado dos componentes de software presentes em um produto, incluindo 
dependências diretas e transitivas|Permite correlacionar uma vulnerabilidade conhecida aos DMIA/SaMD 
realmente expostos|

|2- VEX|Declaração sobre a explorabilidade de vulnerabilidades conhecidas em determinado produto 
ou configuração|Evita interrupções e correções desnecessárias, desde que baseada em evidência verificável|

|3 - AI-BOM / ML-BOM|Inventário ampliado de modelos, pesos, datasets, bibliotecas, frameworks, serviços 
e proveniência envolvidos em um sistema de IA|Ajuda a rastrear alteração de modelo, contaminação de 
dados, dependência externa e responsabilidade|

|4 - Proveniences|Evidências assinadas sobre quem produziu um artefato, em qual ambiente, com quais
entradas e etapas de build|Reduz o risco de aceitar software ou modelos gerados por pipelines não autorizados|

|5 - Atestação|Declaração verificável de que uma etapa, teste, política ou condição foi executada|Aumenta 
auditabilidade e permite bloquear| |implantação quando requisitos essenciais não foram comprovados|

3. Nem todo incidente de terceiro é um ataque de supply chain

- A precisão conceitual evita análises superficiais. 

- Três classes de fenômenos podem coexistir e produzir efeitos semelhantes, mas 
possuem  mecanismos e controles distintos:

a) Classe - b) Mecanismo - c) Exemplo - d) Controle predominante

# 1a Classe 
a) Comprometimento da cadeia de desenvolvimento ou distribuição

b) O adversário adultera código, pacote, build, firmware, modelo, assinatura ou atualização 
antes de o artefato chegar ao usuário.

c) Atualização aparentemente legítima contém código malicioso.	

d) Desenvolvimento seguro, build isolado, assinatura, proveniência, SBOM e validação.

# 2a Classe 
a) Abuso de acesso de terceiro	

b) O fornecedor permanece íntegro como produto, mas suas credenciais, estação de 
trabalho ou canal de suporte são comprometidos.	

c) Conta de manutenção remota é usada para entrar na rede hospitalar.	

d) Zero Trust, MFA, PAM/JIT, segmentação, sessão gravada e revogação.

# 3a Classe 
a) Risco sistêmico de concentração ou dependência	

b) Um fornecedor crítico falha ou é atacado, interrompendo simultaneamente 
múltiplas organizações.	

c) Clearinghouse, laboratório ou serviço de nuvem indisponível paralisa fluxos assistenciais.	

d) Redundância, plano de saída, portabilidade, fallback manual e continuidade clínica.

# Regra de análise. 
- Classificar corretamente o evento não reduz sua gravidade. 
- A classificação determina onde intervir: 

1. no produto, 

2. no acesso, 

3. no contrato, 

4. na arquitetura, 

5. na continuidade,

6. em todos esses domínios.

4. Por que a saúde é especialmente exposta

- A saúde reúne características que amplificam o risco da cadeia: 

1. urgência assistencial, 

2. longa vida útil de equipamentos, 

3. coexistência de tecnologias modernas e legadas, 

4. grande diversidade de fornecedores, 

5. integração entre redes clínicas e administrativas, 

6. uso de componentes de código aberto, 

7. acesso remoto para manutenção, 

8. necessidade de disponibilidade contínua,

9. dificuldade de interromper sistemas para atualização ou investigação.

1. Assimetria de conhecimento: 

hospitais sabem utilizar o produto, mas frequentemente não conhecem todas 
as dependências, subcontratações e etapas de fabricação.

2. Dependências transitivas: 

uma biblioteca aparentemente simples pode incorporar dezenas de pacotes mantidos 
por comunidades ou fornecedores distintos.

3. Ciclo de vida prolongado: 

dispositivos permanecem em uso por muitos anos, mesmo após o encerramento do
suporte a sistemas operacionais ou componentes.

4. Validação clínica: 

patches urgentes podem alterar desempenho, interoperabilidade ou comportamento, 
exigindo equilíbrio entre correção rápida e segurança funcional.

5. Conectividade crescente: 
Formam ecossistemas interdependentes:

1. DMIA, 

2. SaMD, 

3. PACS, 

4. prontuário eletrônico, 

5. LIS, 

6. nuvem, 

7. APIs,

8. dispositivos pessoais.

6. Pressão temporal: 

A necessidade de manter o atendimento pode levar à aceitação:
1. de exceções, 
2. acessos permanentes,
3. atualizações insuficientemente verificadas.

7. Concentração: 
Um pequeno número de serviços pode intermediar:

1. pagamentos,

2. prescrições, 

3. exames, 


4. identidade, 

5. imagens,

6. comunicação para milhares de organizações.

8. Impacto humano: 

Uma indisponibilidade ou manipulação pode:

1. atrasar cuidado, 

2. alterar decisões,

3. causar dano, 

4. resultar em perdas financeira ou reputacional.

5. Superfície de ataque ao longo do ciclo de vida

# 5.1 Ataques às dependências de software

A aplicação clínica raramente é escrita integralmente pelo fabricante. 

Ela utiliza sistemas operacionais, bibliotecas criptográficas, frameworks de IA, 
componentes de interface, bancos de dados, drivers, contêineres e módulos de terceiros. 

A vulnerabilidade pode ser acidental ou maliciosamente introduzida, sendo caminhos 
relevantes:

1. Dependency confusion, 

2. typosquatting, 

3. comprometimento de mantenedores, 

4. pacotes abandonados 

5. substituição de artefatos.

# 5.2 Comprometimento do modelo e da cadeia de dados

Nos sistemas de IA, o objeto de confiança não é apenas o código. 
Já que são passíveis de adulteração:

1.	pesos, 

2.	checkpoints, 

3.	tokenizers, 

4.	datasets, 

5.	scripts de pré-processamento, 

6.	serviços de anotação,

7.	modelos-base.

Um backdoor pode permanecer inativo em testes usuais e ser acionado por um 
padrão específico. 

A assinatura do arquivo do modelo não comprova sua adequação clínica, ela apenas
comprova integridade e origem. Portanto, serão necessários testes regulares de:
1.	desempenho,

2.	robustez, 

3.	viés, 

4.	explicabilidade suficiente,
5.	monitoramento de deriva.

# 5.3 Firmware, hardware e chaves

Dispositivos físicos podem incorporar componentes de múltiplos fabricantes. 

São exemplos de potenciais fontes de riscos:
1.	portas de manutenção, 

2.	bootloaders, 

3.	módulos de comunicação, 

4.	chips e firmware 

Assim, a proteção deverá incluir:

1.	secure boot, 

2.	cadeia de confiança, 

3.	armazenamento seguro de chaves, 

4.	atualização assinada, 

5.	inventário de componentes, 

6.	controles contra downgrade para versões vulneráveis.

# 5.4 APIs, nuvem e integrações

Um SaMD pode depender de:

1. uma API de autenticação,

2. um serviço de inferência, 

3. de armazenamento em nuvem ou de um conector ao prontuário. 

A interrupção ou manipulação desses serviços poderá causar transtornos
diversos para a instituição de saúde, por exemplo:
1.	modificar resultados, 

2.	atrasar laudos,

3.	expor dados. 

O risco inclui ainda “quarta parte”: 
o hospital contrata o fabricante, que contrata uma nuvem, 
que utiliza outro serviço de identidade, observabilidade ou processamento.

# 5.5 Acesso remoto de fornecedores
Acesso remoto permanente e amplo é incompatível com o princípio do menor privilégio. 

O fato de uma conexão ser necessária para manutenção não significa que deva permanecer 
aberta, atingir múltiplos segmentos ou utilizar contas compartilhadas. 
A sessão deve ser:

1.	temporária, 

2.	aprovada, 

3.	autenticada fortemente, 

4.	limitada a ativos definidos, 

5.	registrada,

6.	revogável.

6. Do incidente técnico ao dano ao paciente

A análise de risco deve conectar o evento cibernético a perigos clínicos observáveis 
O impacto clínico pode ocorrer mesmo sem exfiltração de dados. 
Podem modificar a trajetória do cuidado o(a): 
1.	perda de disponibilidade de um laboratório,
2.	alteração de uma imagem,
3.	atraso na entrega de uma prescrição,
4.	indisponibilidade de um algoritmo de triagem,
5.	a impossibilidade de atualizar um dispositivo. 

a) Propriedade comprometida	b)Manifestação computacional c) Consequência clínica possível

1. a) Confidencialidade	
b) Exfiltração de prontuários, imagens, telemetria ou credenciais.	
c) Dano à privacidade, chantagem, fraude e perda de confiança; potencial risco físico em casos sensíveis.

2. a) Integridade	
b) Alteração de resultados, parâmetros, modelos, firmware, alarmes ou logs.	
c) Erro diagnóstico, terapia inadequada, alarmes falsos ou suprimidos, dificuldade de reconstruir o evento.

3. a) Disponibilidade	
b) Indisponibilidade de SaMD, PACS, laboratório, nuvem, atualizador ou fornecedor crítico.	
c) Atraso, cancelamento, desvio de pacientes, retorno a processos manuais e sobrecarga da equipe.

4. a) Autenticidade	
b) Artefato, atualização, usuário ou dispositivo não é quem afirma ser.	
c) Instalação de conteúdo malicioso, manutenção indevida e decisões baseadas em fonte falsa.

5. a) Rastreabilidade	
b) Logs incompletos, versões desconhecidas, ausência de proveniência e cadeia de custódia.	
c) Impossibilidade de identificar pacientes expostos, delimitar o incidente e realizar tecnovigilância eficaz.

6. a) Confiabilidade algorítmica	
b) Modelo adulterado, degradado ou treinado com dados contaminados.	
c) Mudança silenciosa de sensibilidade, especificidade, priorização ou recomendação clínica.

7. Casos internacionais e lições para a saúde

•	Casos reais demonstram diferentes modalidades de risco. 

•	Eles não devem ser tratados como equivalentes, mas como evidências de que relações de
confiança e dependências compartilhadas podem propagar impacto em escala. 

•	O caso Synnovis é especialmente didático para a Medicina: 
1.	o alvo imediato foi um prestador laboratorial, 

2.	o efeito clínico ocorreu em hospitais, atenção primária, procedimentos eletivos e fluxos de 
transplante.

•	O incidente mostra que a fronteira do hospital não coincide com a fronteira do cuidado. 

•	A cadeia assistencial deve ser modelada como um sistema único, ainda que distribuído entre 
organizações.


Caso	Natureza	Efeito observado	Lição para DMIA/SaMD
1.	SolarWinds Orion, 2020	
•	Comprometimento clássico da cadeia de software: código malicioso inserido em atualização confiável.	


•	A CISA determinou ações emergenciais e descreveu exploração por meio de versões comprometidas [8].	

•	Assinatura isolada não basta quando o pipeline é comprometido; são necessários build verificável, 
proveniência, segregação de chaves e detecção pós-implantação.

2.	MOVEit Transfer, 2023	
•	Exploração em massa de vulnerabilidade zero-day em software de transferência usado por terceiros.

•	O HHS/HC3 alertou para incidentes no setor de saúde e para a exposição indireta por organizações
e prestadores [9].	

•	Inventário de exposição, notificação rápida, visibilidade de quarta parte e capacidade de correlacionar
fornecedor-versão-dado são essenciais.

3.	Synnovis/NHS, 2024	
•	Ransomware contra fornecedor externo de patologia.	

•	A capacidade de processar exames foi severamente reduzida e mais de 11 mil consultas e procedimentos
foram atrasados [10].	

•	A continuidade clínica deve prever laboratórios alternativos, priorização de exames, procedimentos manuais, 
comunicação e apoio mútuo.

4.	Change Healthcare, 2024	
•	Comprometimento de infraestrutura altamente concentrada de transações de saúde; risco sistêmico de terceiro.	

•	A empresa reportou restauração extensa, mais de US$ 9 bilhões em apoio temporário, US$ 2,2 bilhões em custos
diretos e estimativa de 190 milhões de indivíduos impactados [11].	

•	Mapear concentração, testar rotas alternativas, preservar portabilidade e limitar dependências únicas são
controles de segurança e continuidade.

8. Benefícios de gerir adequadamente a cadeia

1 . Visibilidade	
Conhecer quais fornecedores, versões, modelos e dependências sustentam cada serviço clínico.

2. Resposta acelerada	
Correlacionar CVE, incidente ou alerta a produtos realmente expostos, evitando busca manual e atraso.

3. Priorização clínica	
Distinguir vulnerabilidade de baixo impacto de exposição capaz de comprometer diagnóstico, terapia 
ou continuidade.

4. Aquisição responsável	
Transformar segurança em requisito verificável antes da compra, não em promessa após a implantação.

5. Redução de movimentação lateral
Limitar o alcance de fornecedores e dispositivos por segmentação, identidade forte e menor privilégio.

6. Resiliência	
Manter alternativas, dados exportáveis, procedimentos de downtime e capacidade de substituir um
elo crítico.

7. Auditabilidade e tecnovigilância	
Registrar versões, alterações, incidentes, pacientes potencialmente expostos e ações corretivas.

8. Confiança responsável	
Substituir confiança presumida por confiança baseada em evidências técnicas, contratuais e o
peracionais.

9. Desafios para a classe médica e para os serviços de saúde

O médico não precisa ser desenvolvedor ou analista de malware; porém, a dependência crescente de tecnologias 
conectadas torna a cibersegurança também uma responsabilidade clínica quando o risco técnico afeta o paciente.

1.	Compreender conceitos mínimos: 
•	dependência, 
•	versão, 
•	patch, 
•	SBOM, 
•	integridade, 
•	indisponibilidade, 
•	acesso privilegiado e fallback.

2.	Definir criticidade clínica: 
    Identificar quais sistemas suportam:
•	decisões tempo-dependentes, 
•	terapias de alto risco,
•	monitorização contínua.

3.	Participar da aquisição: 
    Questionar e/ou analisar:
•	atualização, 
•	fim de suporte, 
•	exportação de dados, 
•	modo degradado,
•	acesso remoto,

4.	Resposta a vulnerabilidades.
•	avaliar mudanças, 
•	distinguir entre:
•	correção cibernética urgente
•	modificação capaz de alterar desempenho clínico 
•	exigir revalidação.

5.	Reconhecer sinais: 
•	resultado incoerente, 
•	alteração de versão, 
•	latência incomum, 
•	comportamento diferente após atualização,
•	falha simultânea de serviços.

6.	Treinar downtime: 
    Ser capaz de operar com segurança quando estiver indisponível:
•	SaMD, 
•	PACS,
•	laboratório, 
•	integração,
•	conectividade 

7.	Comunicar e registrar, sem culpabilização precoce: 
•	anomalias potencialmente cibernéticas
•	eventos de segurança do paciente e tecnovigilância, 

8.	Manter julgamento humano: 
•	Impedir que urgência operacional transforme a recomendação algorítmica em autoridade irrefutável.

9.	Papel fundamental do médico:
•	a equipe de cibersegurança identifica a ameaça; 
•	a equipe clínica determina:
1.	o que ela significa para o paciente, 
2.	quanto tempo existe para agir
3.	quais controles compensatórios são aceitáveis

10. Estratégia de defesa em profundidade

Camadas complementares: nenhuma medida isolada é suficiente.

# 10.1  - Governança e aquisição

• Inventário central de fornecedores,:

1. subfornecedores relevantes, 
2. produtos, 
3. versões, 
4. integrações, 
5. dados processados,
6. esponsáveis internos.

•	Classificação por: 

1. criticidade clínica, 
2. privilégio de acesso, 
3. sensibilidade dos dados, 
4. substituibilidade,
5. concentração.

•	Due diligence proporcional ao risco, com evidências e não 
apenas respostas autodeclaradas.

•	Cláusulas de:
1. notificação de incidente e vulnerabilidade,
2. prazo de correção, 
3. suporte, 
4. acesso ,
5. SBOM, 
6. direito de auditoria,
7. requisitos para subcontratados ,
8. eliminação de dados.

•	Plano de saída: 
1. portabilidade, 
2. formato de exportação, 
3. revogação de identidades,
4. migração,
5. retenção  de logs e continuidade.

•	Comitê multidisciplinar incluindo:
1. clínica, 
2. engenharia clínica,
3. TI,
4. segurança, 
5. compras, 
6. jurídico, 
7. privacidade,
8. qualidade,
9. tecnovigilância.

# 10.2 Desenvolvimento seguro e confiança no build

- O NIST SSDF recomenda integrar práticas de desenvolvimento seguro ao 
ciclo de vida do software [12]. 

- A FDA utiliza o conceito de Secure Product Development Framework (SPDF)
para reduzir o número e a severidade de vulnerabilidades ao longo do ciclo de 
vida de dispositivos [1]. 

- Para DMIA/SaMD, isso implica proteger;
1. repositórios, 
2. branches, 
3. revisões, 
4. runners, 
5. secrets, 
6. compiladores, 
7. registries, 
8. chaves,
9. artefatos.


•	Repositórios protegidos, 
•  Revisão obrigatória, 
•  branch protection.

•	Dependências fixadas por versão e hash;
•   Registries internos ou proxies controlados.


•	Runners efêmeros, 
•    Builds reproduzíveis ou herméticos quando viável e segregação de ambientes.

•	Assinatura de:
1. commits, 
2. releases,
3. contêineres,
4. firmware,
5. modelos, 
6. chaves protegidas em hardware 
7. serviço seguro.

•	SBOM/AI-BOM gerada automaticamente e vinculada ao artefato liberado.

•	Testes SAST, DAST,
composição de software, 
1. fuzzing, 
2. análise de segredos, 
3. segurança de APIs,
4. testes de robustez do modelo.

•	Atestação de proveniência e políticas que impeçam promoção de artefato sem
evidências mínimas.

# 10.3 Implantação Zero Trust
•	Identidade individual, MFA resistente a phishing e proibição de contas compartilhadas.

•	PAM e acesso just-in-time para fornecedores; aprovação vinculada a
chamado e duração limitada.

•	Segmentação de redes clínicas, administrativas, dispositivos, visitantes 
e manutenção.

•	mTLS e autenticação mútua para APIs e dispositivos quando tecnicamente possível.

•	Allowlist de destinos, portas, comandos e serviços necessários.

•	Gravação e auditoria de sessões privilegiadas; alertas para comportamento 
fora do padrão.

•	Desabilitação automática de acesso após encerramento do contrato, chamado ou j
anela autorizada.

# 10.4 Integridade de atualizações e modelos

•	Manifest assinado contendo versão, hash, compatibilidade, requisitos e identificador 
do produto.

•	Verificação criptográfica antes da instalação e secure boot quando disponível.

•	Proteção contra rollback para versões vulneráveis.

•	Canal gradual de implantação: laboratório, piloto, subconjunto e produção.

•	Capacidade de rollback seguro e preservação da versão anterior conhecida como íntegra.

•	Testes clínicos e funcionais proporcionais ao impacto da mudança.

•	Registro da versão efetivamente instalada em cada ativo e do modelo 
associado a cada decisão relevante.


# 10.5 Pós-mercado, monitoramento e continuidade
•	Correlação contínua entre SBOM, CVE, VEX, exposição real e criticidade clínica.

•	Canal de divulgação coordenada de vulnerabilidades e contato de segurança ativo.

•	SLAs diferenciados para vulnerabilidades exploradas, críticas e com 
possível dano ao paciente.

•	Detecção de anomalias de rede, identidade, atualização, inferência e desempenho algorítmico.

•	Plano de resposta conjunto com fornecedor, hospital, engenharia clínica e liderança assistencial.

•	Procedimentos de downtime, estoque mínimo de alternativas, rotas manuais 

e comunicação ao paciente quando necessária.

•	Revisão pós-incidente com ações técnicas, contratuais, clínicas e de tecnovigilância.

11. Três cenários clínico-computacionais com códigos defensivos

11.1 Cenário 1 - Dependência adulterada em SaMD de apoio ao diagnóstico por imagem

- Um SaMD utilizado para priorizar angiotomografias depende de uma biblioteca 
de pré-processamento. 

- A conta de um mantenedor externo é comprometida e uma nova versão do pacote inclui código
capaz de exfiltrar metadados e alterar discretamente a normalização  de imagens. 

- O fabricante atualiza automaticamente a dependência por intervalo de versão, o pipeline conclui
os testes e o artefato é liberado. 

- O software permanece funcional, mas a distribuição de escores muda em subgrupos específicos.

# Elemento - Descrição

1.	Vulnerabilidade	

Dependência não fixada por hash, ausência de política para componentes novos e confiança excessiva 
no registry público.

2.	Trajetória	
Mantenedor comprometido → pacote malicioso → CI/CD → imagem do SaMD → hospital.

3.	Impacto clínico	
Priorização incorreta, atraso na revisão de exames urgentes, possível vazamento e dificuldade de
identificar a versão afetada.

4.	Mitigação	
Lockfile com hashes, proxy de dependências, SBOM, allowlist de componentes, revisão de mudanças, 
build isolado, assinatura e monitoramento de desempenho.

5.	Evidência exigida	
SBOM vinculada ao release, hash do artefato, proveniência do build, aprovação da mudança e 
resultado de testes clínicos de regressão.

# Python - política mínima para verificação de SBOM

# tools/check_sbom.py
# Bloqueia o release se a SBOM contiver componente não aprovado
# ou versão explicitamente proibida pela política institucional.

import json
import sys
from pathlib import Path

APPROVED = {
    "pkg:pypi/numpy@1.26.4",
    "pkg:pypi/pydicom@2.4.4",
    "pkg:pypi/scikit-image@0.22.0",
    "pkg:pypi/onnxruntime@1.17.3",
}

DENIED = {
    "pkg:pypi/example-preprocessor@4.2.1",  # versão sob investigação
}


def component_purl(component: dict) -> str | None:
    return component.get("purl")


def main(sbom_path: str) -> int:
    bom = json.loads(Path(sbom_path).read_text(encoding="utf-8"))
    purls = {
        purl for c in bom.get("components", [])
        if (purl := component_purl(c))
    }

    denied_found = sorted(purls & DENIED)
    unknown = sorted(purls - APPROVED)

    if denied_found:
        print("RELEASE BLOQUEADO - componentes proibidos:")
        print("\n".join(denied_found))
        return 2

    if unknown:
        print("RELEASE BLOQUEADO - componentes sem aprovação:")
        print("\n".join(unknown))
        return 3

    print("SBOM aprovada: todos os componentes estão autorizados.")
        print("SBOM aprovada: todos os componentes estão autorizados.")
    return 0


if __name__ == "__main__":
    raise SystemExit(main(sys.argv[1]))

# Nota
- Em produção, a política deve considerar: 
•	fornecedor, 
•	licença, 
•	hash,
•	assinatura, 
•	criticidade, 
•	CVEs, 
•	VEX, 
•	origem do pacote,
•	exceções formalmente aprovadas. 
- O mecanismo é mais eficaz quando integrado ao CI/CD e ao registro 
de releases, impedindo que um artefato não conformante alcance o 
ambiente clínico.

11.2 Cenário - Atualização adulterada de firmware ou modelo de IA

- Um DMIA de monitorização recebe firmware e pesos de modelo por um 
portal do fabricante.

- O servidor de distribuição é comprometido, e o atacante publica um pacote 
com a mesma nomenclatura da versão legítima. 

- O canal utiliza TLS, mas o dispositivo não valida uma assinatura específica do 
artefato nem impede downgrade. 

- A atualização é aceita e passa a suprimir determinados alarmes em uma 
combinação rara de sinais.

# Elemento - Descrição

1.	Vulnerabilidade	

Confiança exclusiva no canal TLS, ausência de assinatura do manifest e 
inexistência de proteção contra rollback.

2.	Trajetória	

Servidor comprometido → pacote adulterado → atualização automática 
→ dispositivo.

3.	Impacto clínico	

Alarmes falsamente negativos, alteração silenciosa de comportamento 
e propagação simultânea para múltiplos ativos.

4.	Mitigação	

Manifest assinado, hash do payload, chave pública ancorada, secure boot, 
monotonic counter, staged rollout, teste funcional e rollback seguro.

5.	Evidência exigida	

Assinatura válida, versão superior à instalada, hash correspondente, 
compatibilidade declarada e log imutável da atualização.

# Python - validação criptográfica e proteção contra rollback
# verify_update.py
# Exemplo didático: valida assinatura Ed25519, hash e anti-rollback.

import base64
import hashlib
import json
from pathlib import Path
from cryptography.hazmat.primitives.asymmetric.ed25519 import Ed25519PublicKey


def sha256_file(path: Path) -> str:
    h = hashlib.sha256()
    with path.open("rb") as f:
        for block in iter(lambda: f.read(1024 * 1024), b""):
            h.update(block)
    return h.hexdigest()


def verify_update(manifest_path: Path, payload_path: Path,
                  signature_path: Path, public_key_raw: bytes,
                  current_version: int) -> dict:
    manifest_bytes = manifest_path.read_bytes()
    signature = base64.b64decode(signature_path.read_text().strip())

    public_key = Ed25519PublicKey.from_public_bytes(public_key_raw)
    public_key.verify(signature, manifest_bytes)  # falha se adulterado

    manifest = json.loads(manifest_bytes)
    new_version = int(manifest["version"])
    if new_version <= current_version:
        raise ValueError("Atualização rejeitada: rollback ou versão repetida")

    observed = sha256_file(payload_path)
    if observed != manifest["sha256"]:
        raise ValueError("Atualização rejeitada: hash do payload divergente")

    if manifest.get("device_family") != "DMIA-MONITOR-X":
        raise ValueError("Atualização rejeitada: família incompatível")

    return manifest  # somente então seguir para ambiente de validação/piloto

# Nota
- A chave pública deve estar protegida contra substituição e a chave privada 
do fabricante deve permanecer em infraestrutura de alta segurança, com 
segregação de funções e rotação controlada.

- A atualização validada criptograficamente ainda precisa passar por testes 
funcionais e clínicos; integridade não é sinônimo de segurança clínica. 

11.3 Cenário - Credenciais comprometidas de empresa de manutenção

• Uma empresa faz manutenção remota em bombas de infusão e monitores, utilizando por 
conveniência uma conta permanente, acesso via VPN a uma sub-rede ampla e uma credencial 
compartilhada entre os técnicos. 

• Quando um endpoint do fornecedor é infectado, o invasor aproveita a conexão legítima par:
1. enumerar serviços, 
2. acessar um servidor de integração,
3. tentar se mover lateralmente até o prontuário eletrônico.


# Elemento - Descrição

1.	Vulnerabilidade	

• conta compartilhada, 
• acesso permanente, 
•  ausência de dispositivo gerenciado, 
•   segmentação insuficiente ,
• sessão não vinculada a chamado.

2.	Trajetória	

Endpoint do fornecedor → VPN → segmento clínico → integração → tentativa de acesso ao PEP.

3.	Impacto clínico	

• Indisponibilidade de dispositivos, 
• alteração de configuração, 
• propagação de ransomware, 
• perda de rastreabilidade.

4.	Mitigação	
• MFA, 
• identidade individual, 
• PAM/JIT, 
• sessão curta, 
• alvo restrito, 
• bastion, 
• gravação, 
• NetworkPolicy/firewall,
• revogação automática.

5.	Evidência exigida	

• Chamado aprovado, 
• técnico identificado, 
• MFA, dispositivo conforme,
• ativo-alvo definido, 
• horário, 
• comandos, 
• logs da sessão.


# Rego/OPA - autorização just-in-time para manutenção remota

# policy/vendor_access.rego
package hospital.vendor_access

import rego.v1

default allow := false

allow if {
    input.user.type == "vendor_technician"
    input.user.mfa == true
    input.user.identity_is_individual == true
    input.device.managed == true
    input.device.security_posture == "compliant"
    input.ticket.status == "approved"
    input.ticket.target_asset == input.request.target_asset
    input.request.source == "vendor_bastion"
    input.request.target_segment == "dmia_maintenance"
    input.request.session_minutes <= 30
    input.request.record_session == true
    input.request.jit_credential == true
}

deny_reason contains "MFA ausente" if not input.user.mfa
deny_reason contains "chamado não aprovado" if input.ticket.status != "approved"
deny_reason contains "alvo diferente do chamado" if input.ticket.target_asset != input.request.target_asset
deny_reason contains "sessão excede 30 minutos" if input.request.session_minutes > 30
deny_reason contains "origem fora do bastion" if input.request.source != "vendor_bastion"

# Nota

- A política transforma condições clínicas e operacionais em requisitos de autorização verificáveis. 

- Em uma implementação real, ela deve ser combinada com:

• segmentação de rede, 

• cofre de credenciais, 

• aprovação humana, 

• monitoração de comandos,

• encerramento automático

 • procedimentos de emergência auditáveis.

12. Brasil versus mundo

- O Brasil dispõe de fundamentos relevantes; o desafio é transformá-los em requisitos operacionais, 
mensuráveis e verificáveis para cadeias digitais cada vez mais complexas.

# Dimensão – Brasil - Estados Unidos - União Europeia / IMDRF

1.	
•	SaMD	RDC nº 657/2022 e materiais de orientação disciplinam regularização 
de SaMD stand-alone [4].	

•	SaMD e funções de software são enquadrados conforme oregime do dispositivo; a orientação de 
2026 abrange dispositivos com risco cibernético [1].	

•	MDR/IVDR e orientações MDCG tratam qualificação, classificação e requisitos de cibersegurança 
para software médico [13].

2.	
Cibersegurança de dispositivos	

•	Guia Anvisa nº 38/2020: abordagem baseada em risco, responsabilidade compartilhada, pré e
pós-mercado, foco em segurança do paciente [3].	

•	Section 524B e orientação FDA: planos e procedimentos pós-mercado, processos para razoável 
garantia de cibersegurança e SBOM para cyber devices [1].	

•	MDCG 2019-16 Rev.1 orienta fabricantes sobre requisitos de cibersegurança do MDR/IVDR [13].

3.	
SBOM	
•	O Guia 38 incentiva inventário e gestão de componentes, mas, nos documentos analisados, não foi
identificada exigência geral equivalente à obrigação norte-americana para todos os cyber devices.	

•	SBOM integra os requisitos legais aplicáveis aos cyber devices e a documentação recomendada
pela FDA [1].

•	IMDRF N73 fornece princípios globais de SBOM; membros incluem Anvisa e Comissão Europeia [5].

4.	
Cadeia de fornecedores

•	LGPD, contratos, gestão de risco, requisitos sanitários e boas práticas podem sustentar controles, 
mas a maturidade é heterogênea.	

•	NIST C-SCRM, HHS/HICP e guias setoriais oferecem modelos detalhados para terceiros e
cadeia [2,7,14].	

•	MDR/IVDR, NIS2 e orientações de cibersegurança reforçam ciclo de vida, risco, vigilância e 
responsabilidades.

5.	
IA em saúde	
•	Regulação e governança evoluem; a rastreabilidade de modelos, dados e terceiros deve ser
incorporada aos processos sanitários e institucionais.	

•	NIST AI RMF e guia setorial de risco de terceiros em IA em saúde de 2026 abordam linhagem, 
auditabilidade e monitoramento [6,15].	

•	A interação entre AI Act e MDR/IVDR vem sendo detalhada em documentos conjuntos, com
atenção a robustez e cibersegurança [16].



- Uma agenda brasileira plausível inclui: 

•	atualização periódica do Guia 38; 


•	requisitos graduais de SBOM e divulgação coordenada; 

•	critérios mínimos para acesso remoto; 


•	definição de períodos de suporte; 

•	integração entre cibersegurança, 

•	tecnovigilância e segurança do paciente; 

•	estímulo à notificação de incidentes sem cultura punitiva

•	orientação específica para: 
1.	modelos de IA, 

2.	dados de treinamento, 

3.	atualizações adaptativas,

4.	dependências de quarta parte.

13. Checklist institucional e indicadores

13.1 Checklist mínimo antes da aquisição ou renovação

1.	O fornecedor entrega inventário de componentes de software e, quando aplicáve
l, de modelos e dados críticos?

2.	Existe política pública de divulgação coordenada de vulnerabilidades e contato
de segurança?

3.	Atualizações são assinadas, verificadas e protegidas contra rollback?

4.	Qual é o prazo de suporte, fim de vida e estratégia para componentes legados?

5.	Quais subfornecedores e serviços de nuvem participam da solução?

6.	O acesso remoto é individual, MFA, just-in-time, segmentado, gravado e revogável?

7.	Há logs suficientes para reconstruir uma alteração, inferência, atualização ou sessão?

8.	O produto funciona em modo degradado ou offline? Qual é o procedimento de downtime?

9.	Os dados e configurações podem ser exportados em formato utilizável para migração?

10.	Qual é o prazo contratual para notificação de incidente e vulnerabilidade crítica?

11.	Como o fabricante avalia impacto clínico de patches, mudanças de modelo e dependências?

12.	A organização possui alternativa se o fornecedor ou serviço ficar indisponível?


# 13.2 Indicadores de maturidade

# Indicador - Interpretação

1.	% de fornecedores críticos com proprietário interno e criticidade revisada	
• Mede governança e responsabilidade.

2.	% de DMIA/SaMD com versão, SBOM/AI-BOM e fim de suporte conhecidos	
• Mede visibilidade técnica.

3.	Tempo médio para correlacionar CVE crítica aos ativos afetados	
• Mede prontidão de resposta.

4.	% de atualizações verificadas criptograficamente	
• Mede integridade da distribuição.

5.	% de acessos de fornecedores realizados por JIT/PAM	
• Mede redução de privilégio permanente.

6.	% de segmentos clínicos com regras explícitas de comunicação	
• Mede contenção e arquitetura.

7.	Tempo para ativar modo de contingência clínica
• Mede resiliência assistencial.

8.	% de contratos críticos com SLA de incidente e plano de saída	
• Mede capacidade de exigir e substituir.

9.	% de mudanças de modelo com validação e rastreabilidade	
• Mede governança de IA pós-implantação.

10.	Número de exercícios conjuntos com fornecedores por ano	
• Mede preparação real, não apenas documental.


# 13.3 Modelo de maturidade em cinco níveis

# Nível – Descrição - Sinal característico

1 - Desconhecido	
• Fornecedores e componentes não estão mapeados; resposta é reativa.	

• A organização descobre dependências somente durante incidentes.

2 - Inventariado	
• Há cadastro de ativos e fornecedores, porém avaliações são pontuais.	

• Sabe-se “quem fornece”, mas não necessariamente “o que contém”.

3 - Controlado	

• Requisitos contratuais, SBOM para ativos críticos, MFA, segmentação e
processos definidos.	

• A aquisição e a operação aplicam controles mínimos obrigatórios.

4 - Verificado	

• Proveniência, 
• assinatura, 
• políticas automatizadas, 
• testes e auditorias por evidência.

• Artefatos e acessos são bloqueados quando não comprovam conformidade.

5 - Resiliente	

• Monitoramento contínuo, 
• alternativas, 
• exercícios, 
• resposta integrada,
• aprendizagem.


• A organização limita impacto clínico mesmo quando um elo é comprometido.

14. Perspectivas futuras

1.	A cadeia de suprimentos da Medicina Inteligente tende a tornar-se 
ainda mais complexa.

2.	Ampliarão a quantidade de componentes e decisões distribuídas:
• modelos de base, 
• agentes de IA, 
• atualizações frequentes, 
• inferência em nuvem, 
• aprendizagem federada, 
• marketplaces de algoritmos, 
• dispositivos conectados,
• integração em tempo real 

3.	As medidas atuais precisarão evoluir em cinco direções principais:

•	AI-BOM padronizada, incluindo: 
1. modelos-base, 
2. pesos, 
3. datasets, 
4. licenças, 
5. serviços externos, 
6. prompts de sistema relevantes ,
7. cadeia de transformação.

•	Atestações criptográficas de treinamento, avaliação, build, aprovação e
implantação de modelos.

•	Ambientes de execução confidencial e verificação remota para componentes 
críticos.

•	Monitoramento contínuo de integridade e desempenho clínico capaz de diferenciar 
deriva, falha operacional e ataque.

•	Contratos e regulação orientados a resultados verificáveis, com responsabilidades
proporcionais ao controle de cada participante.

•	Interoperabilidade de SBOM, VEX, inventários hospitalares, bancos de vulnerabilidades
e plataformas de tecnovigilância.

•	Testes de resiliência e “caos clínico controlado” para verificar se a organização consegue 
operar durante falha de  fornecedores.

•	Mecanismos seguros de atualização de modelos adaptativos, com limites, aprovação, 
trilha de auditoria e possibilidade de reversão.

4.	O futuro desejável não é uma medicina sem fornecedores, mas uma medicina em que 
cada elo relevante possa demonstrar sua identidade, responsabilidade, integridade, versão, 
suporte e capacidade de resposta. 

5.	A transparência técnica deverá tornar-se um atributo de qualidade do dispositivo, não um
documento opcional fornecido apenas após um incidente.

15. Discussão

1.	A gestão da supply chain desafia modelos tradicionais de responsabilidade. 

•	o hospital pode não ter desenvolvido o software; 

•	o fabricante pode não ter criado todas as bibliotecas; 

•	o provedor de nuvem pode não conhecer a finalidade clínica;

•	o médico pode não visualizar qualquer uma dessas relações. 

2.	Ainda assim, o paciente experimenta o sistema como uma unidade. 
A fragmentação contratual e técnica não pode resultar em fragmentação ética.

3.	Também é necessário evitar o “teatro de conformidade”. 
Conseguem coexistir com acessos permanentes:

•	questionários extensos, 

•	certificados genéricos,

•	cláusulas amplas 

•	inventários incompletos, 

•	ausência de contingência. 


4.	Evidências de segurança devem ser específicas ao:

•	produto,

•	versão,

•	contexto de implantação,

•	à função clínica. 
 
5.	Uma organização certificada pode fornecer um componente vulnerável; 

6.	um produto com SBOM pode continuar inseguro; 

7.	uma atualização assinada pode ter sido produzida por pipeline comprometido. 

8.	Por isso, controles precisam ser combinados.

•	A segurança da cadeia é um problema sistêmico: 
Dependem da integração entre:
1. governança, 
2. engenharia, 
3. contratação,
4. identidade, 
5. arquitetura, 
6. monitoramento, 
7. validação clínica,
8. tecnovigilância. 
9. SBOMs, 
10. alertas, 
11. patches e planos de contingência. 


Geram valor quando conectados ao 
1. inventário real, a responsáveis definitivos, 
2.  à capacidade de validação ,
3.  à prática treinada.

•	Para a classe médica, o ponto central é reconhecer que a cadeia invisível
também integra o ato assistencial. 

A confiabilidade do resultado dependerá:
1. do algoritmo, 
2. da integridade do código, 
3. do modelo, 
4. da infraestrutura, 
5. das atualizações,
6. dos fornecedores,
7. das integrações; 

Portanto,  o julgamento médico segue indispensável para relacionar anomalias tecnológicas 
ao contexto real do paciente.

16. Considerações finais

•	Do código ao leito do paciente existe uma cadeia extensa de confiança capaz de fortalecer ou fragilizar
o  cuidado.  Seu pipeline envolve;
1.	pacote, 
2.	modelo, 
3.	firmware, 
4.	chave, 
5.	servidor, 
6.	API, 
7.	integrador,
8.	técnico. 
9.	subfornecedor.

•	A resposta não consiste em paralisar a inovação, rejeitar componentes de terceiros ou presumir 
má-fé dos fornecedores, mas sim em exigir:

1.	transparência proporcional ao risco, 
2.	reduzir privilégios, 
3.	verificar artefatos, 
4.	conhecer dependências, 
5.	monitorar mudanças, 
6.	preparar alternativas,
7.	integração o impacto clínico à resposta cibernética. 

•	A cadeia precisa ser tratada como parte do sistema:
1.	médico,
2.	de qualidade.

•	A Medicina  inteligente:

1.	se inicia na origem do código, dos dados e dos componentes; 

2.	atravessa o desenvolvimento, a fabricação, a distribuição e a manutenção;

3.	precisa permanecer íntegra até o momento em que a tecnologia participa de uma decisão sobre
um ser humano. 

•	A segurança de um DMIA ou SaMD depende da confiabilidade sobre itens que participam de seu
ciclo de vida. Dentre eles:

1.	componentes, 
2.	dados, 
3.	modelos, 
4.	fornecedores e subfornecedores, 
5.	processos,
6.	atualizações, 
7.	integrações,
8.	acessos.

17. Referências

1. FOOD AND DRUG ADMINISTRATION (FDA). Cybersecurity in Medical Devices: Quality Management System Considerations and Content of Premarket Submissions. Final Guidance, 3 fev. 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/cybersecurity-medical-devices-quality-management-system-considerations-and-content-premarket
2. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). SP 800-161 Rev. 1 Update 1: Cybersecurity Supply Chain Risk Management Practices for Systems and Organizations. 2024. https://doi.org/10.6028/NIST.SP.800-161r1-upd1
3. AGÊNCIA NACIONAL DE VIGILÂNCIA SANITÁRIA (ANVISA). Guia nº 38/2020: Princípios e práticas de cibersegurança em dispositivos médicos. Versão 1, 2020. https://www.gov.br/anvisa/pt-br/assuntos/noticias-anvisa/2020/saiba-mais-sobre-ciberseguranca-em-dispositivos-medicos/guia-38.pdf
4. AGÊNCIA NACIONAL DE VIGILÂNCIA SANITÁRIA (ANVISA). RDC nº 657/2022 e Perguntas e Respostas sobre Software como Dispositivo Médico (SaMD). 2022. https://www.gov.br/anvisa/pt-br/assuntos/noticias-anvisa/2022/software-como-dispositivo-medico-perguntas-e-respostas
5. INTERNATIONAL MEDICAL DEVICE REGULATORS FORUM (IMDRF). IMDRF/CYBER WG/N73 FINAL:2023. Principles and Practices for Software Bill of Materials for Medical Device Cybersecurity. 2023. https://www.imdrf.org/documents/principles-and-practices-software-bill-materials-medical-device-cybersecurity
6. HEALTH SECTOR COORDINATING COUNCIL (HSCC). Third-Party AI Risk and Supply Chain Transparency Guide. 2026. https://healthsectorcouncil.org/wp-content/uploads/2026/04/AI-Third-Party-Risk-Guide.pdf
7. HEALTH SECTOR COORDINATING COUNCIL (HSCC). Health Industry Cybersecurity Supply Chain Risk Management Guide - HIC-SCRiM, Version 2.0. 2023. https://healthsectorcouncil.org/wp-content/uploads/2023/10/HIC-SCRiM_2023-2.pdf
8. CYBERSECURITY AND INFRASTRUCTURE SECURITY AGENCY (CISA). Supply Chain Compromise / SolarWinds Orion guidance. 2020-2021. https://www.cisa.gov/news-events/alerts/2021/01/07/supply-chain-compromise
9. U.S. DEPARTMENT OF HEALTH AND HUMAN SERVICES, HEALTH SECTOR CYBERSECURITY COORDINATION CENTER (HC3). Threat Actor Profile: FIN11 and MOVEit exploitation. 2023. https://www.hhs.gov/sites/default/files/threat-profile-june-2023.pdf
10. NHS ENGLAND. Synnovis cyber incident. Atualizações oficiais sobre o ataque de 3 jun. 2024 e seus impactos assistenciais. https://www.england.nhs.uk/synnovis-cyber-incident/
11. UNITEDHEALTH GROUP. Annual Report / Form 10-K for the year ended December 31, 2024. Informações sobre o incidente Change Healthcare. https://www.sec.gov/Archives/edgar/data/731766/000073176625000063/unh-20241231.htm
12. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). SP 800-218: Secure Software Development Framework (SSDF) Version 1.1. 2022. https://csrc.nist.gov/pubs/sp/800/218/final
13. MEDICAL DEVICE COORDINATION GROUP (MDCG). MDCG 2019-16 Rev.1: Guidance on Cybersecurity for Medical Devices. 2020. https://health.ec.europa.eu/system/files/2022-01/md_cybersecurity_en.pdf
14. U.S. DEPARTMENT OF HEALTH AND HUMAN SERVICES (HHS). Health Industry Cybersecurity Practices (HICP) 2023 Edition e HPH Cybersecurity Performance Goals. https://hhscyber.hhs.gov/cornerstone-hicp.html
15. NATIONAL INSTITUTE OF STANDARDS AND TECHNOLOGY (NIST). Artificial Intelligence Risk Management Framework (AI RMF 1.0). 2023. https://doi.org/10.6028/NIST.AI.100-1
16. EUROPEAN COMMISSION. AIB 2025-1 / MDCG 2025-6: Interplay between the Medical Devices Regulation, In Vitro Diagnostic Medical Devices Regulation and Artificial Intelligence Act. 2025. https://health.ec.europa.eu/document/download/b78a17d7-e3cd-4943-851d-e02a2f22bbb4_en
17. CYBERSECURITY AND INFRASTRUCTURE SECURITY AGENCY; NIST. Defending Against Software Supply Chain Attacks. 2021. https://www.cisa.gov/sites/default/files/publications/defending_against_software_supply_chain_attacks_508.pdf
18. ISO/IEC. ISO/IEC 27036 - Information security for supplier relationships. Série de normas. https://www.iso.org/standard/59648.html
19. INTERNATIONAL ELECTROTECHNICAL COMMISSION. IEC 81001-5-1 - Health software and health IT systems safety, effectiveness and security: activities in the product life cycle. https://webstore.iec.ch/en/publication/66559
20. U.S. DEPARTMENT OF HEALTH AND HUMAN SERVICES (HHS). HPH Cybersecurity Performance Goals. https://hhscyber.hhs.gov/cybersecurity-performance-goals.html
Acesso às referências eletrônicas: julho de 2026.

Olá, Ricardo!

Parabéns pela contribuição altamente Relevante ao fórum.

O seu texto oferece uma visão equilibrada e bem estruturada sobre como a cibersegurança impacta diretamente a segurança do paciente no ambiente hospitalar. A abordagem mantém um tom objetivo ao conectar os riscos da cadeia de suprimentos a soluções concretas, como o uso de SBOM, controle Zero Trust e a implementação de verificações defensivas em Python e Rego/OPA.

É um material muito didático, que apresenta análises fundamentadas sem excessos e traz exemplos práticos de grande valor para a discussão de DMIA e SaMD na saúde digital. Importante iniciativa para fomentar o debate técnico na comunidade com equilíbrio e precisão.

Qual ponto do seu artigo você considera o passo inicial mais acessível para equipes que estão começando essa jornada?

Olá, Rafaela,
Agradeço pela análise.

De fato, este artigo é extremamente necessário, mas ao mesmo tempo aborda um tema que a classe
médica talvez nem saiba que existe. Tenho comentado há alguns meses que é preciso trazer à luz do debate diversos
assuntos relacionados à medicina assistida por inteligência artificial. Esse é miha resposta para a sua pergunta...

Att,
Ricardo