Cibersegurança para fabricantes de software e equipamentos marítimos
Os navios funcionam hoje com software de dezenas de fornecedores, e as regras de classificação e o direito da UE esperam que cada fornecedor saiba o que está no seu software e o mantenha seguro. O CRACI executa os seus builds de GitHub Actions e regista todos os componentes que entram em cada release.
Que regras se aplicam a que produtos marítimos
Um fornecedor do setor marítimo responde a três regimes que se sobrepõem mas não coincidem: a legislação de produtos da UE, as regras de classificação para navios novos e as orientações da Organização Marítima Internacional (OMI) para os operadores de navios. Determine qual se aplica a cada produto antes de planear as evidências.
O CRA exclui os equipamentos da Diretiva Equipamentos Marítimos
O artigo 2.º, n.º 4, do Cyber Resilience Act, Regulamento (UE) 2024/2847, diz: «O presente regulamento não se aplica aos equipamentos abrangidos pelo âmbito de aplicação da Diretiva 2014/90/UE.» Essa diretiva, a Diretiva Equipamentos Marítimos (MED), abrange os equipamentos colocados ou a colocar a bordo de um navio da UE para os quais as convenções da OMI exigem a aprovação da administração do Estado de bandeira: os equipamentos com wheel mark (a marca da roda do leme). São exemplos os equipamentos de navegação como o radar, o ECDIS, o AIS e os registadores de dados de viagem, os equipamentos de radiocomunicações, a proteção contra incêndios e os meios de salvação. Verifique a lista de execução em vigor da MED para o seu próprio equipamento.
O que continua no âmbito do CRA
Os produtos com elementos digitais colocados no mercado da UE que não são equipamentos da MED: software de bordo e de terra vendido como produto, instalado ou descarregado; sistemas de operações do navio, de alojamento, de restauração e de gestão hoteleira; sistemas de serviço à tripulação e aos passageiros; software de gestão de frotas e de viagens; sensores e gateways IoT de bordo; equipamentos de monitorização e automação que não precisam de aprovação do Estado de bandeira. O software como serviço, por si só, está fora do CRA, salvo se for o tratamento remoto de dados de um produto, embora a NIS2 possa continuar a aplicar-se ao seu prestador.
Alguns casos precisam de uma análise jurídica em vez de uma regra: equipamentos de um tipo com wheel mark vendidos para navios que não arvoram pavilhão da UE, e produtos que combinam equipamentos da MED com módulos de software fora da MED.
IACS UR E26 e E27
Os requisitos unificados da Associação Internacional das Sociedades de Classificação aplicam-se através da classificação, não do direito da UE. A Rev.1 de ambos aplica-se aos navios cujo contrato de construção seja celebrado em ou após 1 de julho de 2024. São obrigatórios para navios de passageiros e embarcações de alta velocidade em viagens internacionais, navios de carga de 500 GT ou mais em viagens internacionais, unidades móveis de perfuração offshore e determinadas unidades offshore autopropulsionadas, e servem de orientação para os restantes navios. Um produto fora do CRA por causa da MED pode continuar no âmbito das E26 e E27, e vice-versa.
OMI
A Resolução MSC.428(98) pede aos operadores de navios que tratem os riscos cibernéticos nos seus sistemas de gestão da segurança, o mais tardar na primeira verificação anual do Documento de Conformidade da companhia após 1 de janeiro de 2021. As diretrizes da OMI sobre a gestão dos riscos cibernéticos marítimos são orientações não obrigatórias e de alto nível para os operadores. A sua revisão mais recente, de maio de 2026, diz que a gestão dos riscos cibernéticos deve ter em conta os fornecedores terceiros, os sistemas embebidos e as cadeias de abastecimento de software e hardware, e pede aos operadores que estabeleçam políticas de segurança da cadeia de abastecimento de software e hardware para os sistemas críticos. É por isso que os operadores passam a pergunta aos seus fornecedores.
| Exemplo de produto | Com wheel mark (MED)? | Cyber Resilience Act | IACS UR E26 e E27 | O que o fornecedor tem de demonstrar |
|---|---|---|---|---|
| ECDIS | Sim | Excluído (artigo 2.º, n.º 4) | Sim, em navios novos abrangidos | Aprovação MED; documentação E27 e inventário de software |
| Sistema de automação do motor num navio de carga em construção | Verificar | Sim, salvo se for equipamento da MED | Sim: a propulsão é um sistema abrangido | Documentação E27, inventário e ciclo de vida de desenvolvimento seguro; documentação técnica e SBOM do CRA |
| Software de gestão hoteleira e de restauração | Não | Sim, quando vendido como produto | Verificar: a E26 abrange a sua interface de rede com os sistemas abrangidos | SBOM e tratamento de vulnerabilidades para o CRA |
| Equipamento de rede para o bem-estar da tripulação | Não | Sim | Verificar: a E26 abrange a sua interface com os sistemas abrangidos | SBOM e tratamento de vulnerabilidades para o CRA |
| Software de gestão de frotas como serviço | Não | Fora, salvo se for o tratamento remoto de dados de um produto | Não: funciona em terra | Respostas aos questionários de fornecedores dos operadores; a NIS2 pode aplicar-se ao prestador |
| Sensores de monitorização do estado a bordo | Verificar | Sim, salvo se forem equipamentos da MED | Verificar: abrangidos quando fazem parte de um sistema abrangido | SBOM do CRA; documentação E27 quando fazem parte de um sistema abrangido |
A regra prática: se o seu produto precisa de wheel mark, o CRA não se lhe aplica; se vai para um navio contratado a partir de julho de 2024, a E27 provavelmente aplica-se; se vende software ou produtos ligados na UE, parta do princípio de que o CRA se aplica.
O que as E26 e E27 pedem aos fornecedores
A E27 é o requisito que chega diretamente aos fornecedores de equipamentos. A secção 3.1 enumera os documentos que um fornecedor apresenta à sociedade de classificação para um sistema informático, entre eles:
- Um inventário de ativos (3.1.1): os componentes de hardware, com o nome, a versão e o nível de patches do seu software de sistema, como o sistema operativo e o firmware, e os componentes de software, cada um com o hardware em que está instalado, o seu fabricante, modelo ou tipo, finalidade e versão de software.
- Uma descrição das capacidades de segurança (3.1.3) e do respetivo procedimento de ensaio, diretrizes de configuração de segurança e planos de manutenção, resposta a incidentes, recuperação e gestão da mudança.
- Documentos do ciclo de vida de desenvolvimento seguro (3.1.6), que descrevem também como são tratadas as atualizações e os patches de software.
A secção 4 define as capacidades de segurança exigidas, com base em requisitos de sistema selecionados da IEC 62443-3-3, como a autenticação e a proteção contra código malicioso. São capacidades do produto.
A secção 5 exige um ciclo de vida de desenvolvimento seguro que abranja requisitos, conceção, implementação, verificação, release, manutenção e fim de vida, registado num documento revisto pela sociedade de classificação. Tem de incluir controlos retirados da IEC 62443-4-1: proteção das chaves de assinatura de código (SM-8), documentação das atualizações de segurança para os utilizadores (SUM-2), documentação das atualizações de segurança de componentes dependentes ou do sistema operativo (SUM-3), entrega autêntica das atualizações (SUM-4) e orientações de defesa em profundidade e de hardening (SG-1 a SG-3).
A E26 fecha o ciclo ao nível do navio: o inventário de ativos do navio, de hardware e software, com os campos do inventário E27 de cada fornecedor, é mantido atualizado durante toda a vida do navio, e nele são registadas as alterações de software e hardware que possam introduzir novas vulnerabilidades.
O que a E27 não diz: não refere SBOM. Uma SBOM por release é a forma mais precisa de obter as versões de software para o inventário e a informação da SUM-3 sobre componentes dependentes, mas apoia esses requisitos em vez de ser um deles.
| Requisito E26 ou E27 | O que a sociedade de classificação ou o estaleiro espera | Evidências do build | O que fica a seu cargo |
|---|---|---|---|
| Inventário de ativos E27 (3.1.1) | Cada componente de software com a sua finalidade e versão, e o software de sistema de cada componente de hardware | Uma SBOM por release, com cada componente e a sua versão | Em que hardware está instalado cada componente, e os dados de fabricante e modelo |
| Documentação de atualizações SUM-2 e SUM-3 | Atualizações de segurança documentadas, incluindo para componentes dependentes e sistemas operativos | Registos de vulnerabilidades e histórico de builds dos componentes de cada release | As notas de atualização e os avisos de segurança que envia aos utilizadores |
| SM-8 e SUM-4 | Chaves de assinatura de código protegidas e entrega autêntica das atualizações | Nenhuma: o CRACI não assina software | O seu processo de assinatura e o armazenamento de chaves |
| Capacidades de segurança da secção 4 | Autenticação, proteção contra código malicioso e outras capacidades do produto | Nenhuma: são funcionalidades do produto | O design do produto e os respetivos ensaios |
| Documento de ciclo de vida da secção 5 | Uma descrição revista de como a segurança é tratada em cada fase | Registos de que a fase de release está controlada: o que cada build continha e o que podia alcançar | Redigir o documento e executar o processo |
| Inventário de ativos do navio E26 | O inventário do navio, mantido atualizado durante toda a sua vida | As suas exportações de SBOM, entregues ao integrador | Que versão está instalada em que navio, e a entrega ao estaleiro ou ao integrador |
Porque é difícil acompanhar o software marítimo
Os navios duram mais do que os projetos. Um navio fica em serviço durante décadas, e o esforço de suporte do software de bordo dura mais do que o projeto que o entregou, a equipa que o construiu e, muitas vezes, a própria linha de produtos do fornecedor.
Muitos fornecedores e integradores pequenos. Um único navio leva software de dezenas de fornecedores, montado por um integrador, e cada entrega é uma oportunidade de perder o rasto ao que está em cada release.
Os sistemas de bordo não podem ser atualizados quando se quer. As atualizações esperam por escalas em porto, pela aprovação da classe ou por uma janela de manutenção, por isso as versões antigas continuam em serviço muito depois de existir uma correção. Precisa de saber que navios ainda executam que versão.
Locais remotos, conectividade limitada. Os navios no mar e as instalações remotas são difíceis de alcançar, por isso o registo do que foi instalado tem de existir em terra, a partir do build, e não da análise do navio.
Folhas de cálculo como sistema de registo. Os fabricantes de software marítimo dizem-nos que as SBOM e os registos relacionados vivem em muitas folhas de cálculo, mantidas à mão. Ficam desatualizadas a cada release.
Como se preparar, passo a passo
As capacidades de segurança, como a autenticação, fazem parte do design do produto. Os passos abaixo cobrem as evidências sobre o software que entra nele.
- Associe cada produto ao seu regime. Para cada produto, decida se é um equipamento da MED, um produto do CRA, se está no âmbito das E26 e E27, ou várias destas coisas. O plano de evidências decorre desse mapa.
- Produza uma SBOM para cada release. Registe o que entra em cada release de cada produto que constrói, incluindo as dependências transitivas, para que o inventário de software venha do build e não da memória.
- Mantenha um inventário por instalação. Acompanhe que versão está instalada em que navio e quando mudou. Isto alimenta o inventário de ativos E27 e o inventário de ativos do navio E26 do integrador, que regista as alterações durante toda a vida do navio.
- Monitorize as vulnerabilidades e reporte. Volte a verificar as releases distribuídas à medida que são publicadas novas vulnerabilidades. Para os produtos no âmbito do CRA, o reporte de vulnerabilidades ativamente exploradas e de incidentes graves aplica-se desde 11 de setembro de 2026.
- Impeça que pacotes com vulnerabilidades conhecidas entrem nos builds. Bloqueie um build que iria distribuir uma vulnerabilidade conhecida, para que não regresse através de uma atualização de dependências.
- Documente as atualizações de segurança para clientes e integradores. Diga aos clientes e integradores o que cada atualização de segurança corrige, incluindo correções em componentes dependentes e no sistema operativo, como esperam a SUM-2 e a SUM-3.
Onde o CRACI se encaixa
O CRACI executa os seus builds de GitHub Actions nos seus próprios runners e regista o que entra em cada release. Esse registo é a evidência comum por trás do CRA, da sua documentação E27 e das perguntas dos seus clientes.
Cada release registada
Os seus builds são executados nos runners de GitHub Actions do CRACI com runs-on: craci, e as execuções continuam a aparecer no GitHub. Durante cada build, o CRACI regista todos os pacotes que obtém, incluindo npm e PyPI, com as dependências ocultas que nenhum lockfile lista e um estado de completude para cada job. As SBOM são exportadas em CycloneDX ou SPDX com dependências transitivas, licenças declaradas e as vulnerabilidades encontradas nos seus componentes: a matéria-prima para a parte de software de um inventário de ativos E27. Saiba mais sobre SBOM registadas durante o build.
Mantenha de fora os pacotes vulneráveis
Os policy gates podem bloquear um build que contenha uma CVE específica, e as regras de política de licenças podem bloquear um build por causa de uma licença. Um problema conhecido é detetado na CI, antes de a release chegar a um navio.
Saiba que releases estão afetadas
O CRACI continua a reavaliar as SBOM monitorizadas à medida que são publicadas novas vulnerabilidades, e o histórico de builds mostra que builds continham a dependência vulnerável, dentro do período de retenção do seu plano. A vista de inventário mostra que versões de software estão implementadas em que produtos. As equipas de segurança fazem a triagem de cada conclusão e encaminham-na para a equipa responsável pela correção. Para produtos abrangidos pelo CRA, o CRACI prepara o conteúdo das notificações do CRA, e uma pessoa da sua empresa submete-as através da Single Reporting Platform.
Um build que não pode divulgar os seus segredos
Cada job é executado na sua própria máquina virtual isolada, sob uma política de egress que pode configurar com negação por predefinição, validada antes de o job arrancar e com falha em modo fechado. Com uma política de negação por predefinição, uma ligação a um host de que o build não precisa é bloqueada e gera um alerta.
Quando o CRACI não é a resposta
O CRACI é para equipas que constroem software. Não serve para estes casos:
- Não para operadores e armadores de navios que procuram monitorização da rede de bordo, deteção de intrusões, conformidade com a E26 ao nível do navio ou documentação para o seu sistema de gestão da segurança. O CRACI é para quem constrói o software, não para a frota que o utiliza.
- Não é um programa CRA para fabricantes de equipamentos da MED: os equipamentos com wheel mark estão fora do CRA. O CRACI pode, ainda assim, registar os builds de software por trás deles para a E27 e para pedidos de clientes, se forem executados em GitHub Actions.
- Não para fornecedores que não constroem em GitHub Actions, que precisam de máquinas de build Windows ou macOS, ou que precisam de runners dentro da sua própria conta na cloud. Hoje o CRACI disponibiliza runners Linux geridos em infraestrutura europeia; outros sistemas de CI, runners Windows e macOS e runners alojados pelo cliente estão no roadmap.
- Não para listas de materiais de hardware. O CRACI regista software; não gere BOM de hardware.
- Não as capacidades de segurança da E27 nem uma aprovação da classe. O CRACI não implementa autenticação, proteção contra malware ou outras capacidades do produto, não assina software, não redige o seu documento de ciclo de vida de desenvolvimento seguro e não trata com a sociedade de classificação por si.
- Não é uma ferramenta de métricas de remediação: o CRACI não reporta o tempo médio de remediação nem prazos de remediação.
A cibersegurança marítima explicada
Perguntas comuns sobre o CRA, as IACS UR E26 e E27 e as diretrizes da OMI para fornecedores do setor marítimo
O Cyber Resilience Act aplica-se aos equipamentos marítimos?
Não aos equipamentos no âmbito da Diretiva Equipamentos Marítimos, 2014/90/UE. O artigo 2.º, n.º 4, do CRA exclui-os expressamente. Isso abrange os equipamentos com wheel mark que precisam de aprovação do Estado de bandeira ao abrigo das convenções da OMI. Outros produtos ligados e software vendidos para navios, como sistemas hoteleiros, redes da tripulação, sensores e software de frota instalado a bordo, podem continuar abrangidos pelo CRA.
Que produtos marítimos estão excluídos do CRA?
Os equipamentos no âmbito da Diretiva Equipamentos Marítimos: equipamentos colocados a bordo de navios da UE para os quais as convenções da OMI exigem aprovação do Estado de bandeira, como o radar, o ECDIS, o AIS, os registadores de dados de viagem, as radiocomunicações, a proteção contra incêndios e os equipamentos de salvação. Verifique a lista de execução em vigor da MED para o seu equipamento, e peça uma análise jurídica para produtos mistos ou navios com outras bandeiras.
O que é a IACS UR E27, e quem tem de a cumprir?
A UR E27 é o requisito unificado da Associação Internacional das Sociedades de Classificação sobre a ciber-resiliência dos sistemas e equipamentos de bordo. A Rev.1 aplica-se aos navios cujo contrato de construção seja celebrado em ou após 1 de julho de 2024, e é obrigatória para navios de passageiros, embarcações de alta velocidade e navios de carga de 500 GT ou mais em viagens internacionais, e para determinadas unidades offshore. Os fornecedores de sistemas abrangidos cumprem-na através da sociedade de classificação.
O que exigem as E26 e E27 aos fornecedores de equipamentos?
A E27 pede aos fornecedores documentação que inclui um inventário de ativos que lista cada componente de software com a sua versão, capacidades de segurança baseadas na IEC 62443-3-3 e um ciclo de vida de desenvolvimento seguro com controlos da IEC 62443-4-1, como a documentação das atualizações de segurança. A E26 é o requisito ao nível do navio: o inventário de ativos do navio usa os mesmos campos e é mantido atualizado durante toda a vida do navio.
A UR E27 exige uma SBOM?
Não. A E27 não refere SBOM. Pede um inventário de ativos que liste cada componente de software com a sua versão, e documentação das atualizações de segurança de componentes dependentes e do sistema operativo. Uma SBOM por release é a forma mais precisa de obter essa informação, mas não é um requisito da E27.
As diretrizes da OMI sobre gestão dos riscos cibernéticos são obrigatórias?
Não. As diretrizes da OMI sobre a gestão dos riscos cibernéticos marítimos são orientações não obrigatórias para os operadores de navios, revistas em maio de 2026. O que se espera dos operadores vem da Resolução MSC.428(98), que lhes pede que tratem os riscos cibernéticos nos seus sistemas de gestão da segurança, e as diretrizes pedem agora aos operadores que definam políticas de segurança da cadeia de abastecimento de software e hardware.
O CRA aplica-se ao software vendido a companhias de navegação?
Normalmente sim, se for vendido no mercado da UE como produto com elementos digitais, instalado ou descarregado, e não for equipamento da MED. O software oferecido puramente como serviço está fora do CRA, salvo se for o tratamento remoto de dados de um produto, embora a NIS2 possa aplicar-se ao seu prestador. Verifique a classificação de cada produto.
Veja o que entra nas suas releases
Marque uma demo e mostraremos todos os componentes que os seus builds obtêm, e que releases uma nova vulnerabilidade afeta.
Marcar demo