Tema: compliance
-
Logs de auditoria: o que registrar, como mantê-los íntegros e quem pode lê-los
Um log de auditoria responde a quem fez o quê, em qual objeto, quando e com que resultado. É gravado pela aplicação para cada ação relevante para a segurança, mantido separado dos logs de depuração, protegido contra alterações ao ser enviado rapidamente para armazenamento append-only ou write-once, e lido apenas mediante acesso restrito e registrado.
-
Preparar o fluxo de tratamento de vulnerabilidades de um fabricante para o CRA: recebimento, evidências e contagem dos prazos de notificação
Um protocolo de preparação proposto conecta o recebimento de relatos de vulnerabilidades e os registros de componentes à decisão de notificar segundo o CRA. Ele separa a obrigação de notificação já aplicável em 2026 dos requisitos mais amplos de tratamento de vulnerabilidades aplicáveis em dezembro de 2027.
-
Verificar o ciclo de vida de suporte de um sistema operacional antes de automatizar sobre ele
Automatizar fluxos de patch, upgrade ou conformidade em um host que já passou do fim de vida (EOL) gera falsa confiança: não virão mais correções de segurança, independentemente do que a automação reporte. Esta metodologia indica onde cada grande fornecedor publica as datas de ciclo de vida e como incluir uma verificação de EOL em uma etapa de pré-verificação.
-
Como escolher uma licença de código aberto
Licenças permissivas (MIT, Apache-2.0) permitem a reutilização mediante atribuição; licenças copyleft (GPL, AGPL) exigem que os trabalhos derivados continuem abertos; a Apache-2.0 acrescenta uma concessão de patentes. Escolha conforme o que os usuários downstream devem poder fazer e verifique a compatibilidade das dependências.
-
Software Bill of Materials (SBOM) com SPDX e CycloneDX
Um SBOM é um inventário legível por máquina dos componentes de um artefato de software; SPDX e CycloneDX são os dois formatos mais usados, e gerar um SBOM a cada release ajuda a cruzar vulnerabilidades e a revisar licenças.
-
Notificações do CRA desde setembro de 2026: critérios, prazos e a Single Reporting Platform
O CRA exige que fabricantes notifiquem vulnerabilidades de produtos exploradas ativamente e incidentes graves de segurança de produtos. Ambos têm etapas de 24 horas e 72 horas, mas os prazos dos relatórios finais são contados a partir de eventos diferentes.
-
Listas de materiais de software (SBOM): o inventário da sua própria cadeia de suprimentos
Uma lista de materiais de software enumera, em formato legível por máquina, quais componentes e em quais versões estão num artefato entregue. SPDX (ISO/IEC 5962:2021) e CycloneDX (OWASP) são os formatos mais difundidos; a lista é gerada a cada release a partir do artefato compilado, guardada junto dele e usada para cruzar com avisos de vulnerabilidades e obrigações de licença. Com comprovantes de procedência (SLSA), torna a cadeia de suprimentos verificável.
-
CIS Benchmarks e DISA STIGs como base de hardening: o que são e como aplicá-los de forma seletiva
CIS Benchmarks e DISA STIGs são dois conjuntos de recomendações de configuração mantidos de forma independente, ambos com níveis de perfil selecionáveis em vez de uma meta única. Aplicar um perfil inteiro sem registrar exceções é uma forma comum de o trabalho de hardening derrubar um serviço em produção.
-
Notificação de ciberataques na Suíça e CRA: obrigações distintas para operadores e fabricantes de produtos
A notificação suíça para infraestrutura crítica diz respeito a ciberataques que atendem aos critérios legais contra operadores abrangidos. O CRA diz respeito a fabricantes de produtos que abastecem o mercado da UE, incluindo fabricantes suíços; prazos iniciais semelhantes não tornam os destinatários nem os critérios de notificação intercambiáveis.
-
CRA e código aberto: distinguir colaboradores, fabricantes e administradores
Uma licença de código aberto, por si só, não determina as obrigações do CRA. O regulamento distingue o fornecimento comercial de produtos, as contribuições para software fora da responsabilidade de quem contribui e o apoio contínuo de administradores de software de código aberto, cujas obrigações do artigo 24 começam em dezembro de 2027.
-
Verificação de um host Linux em relação a uma baseline com o OpenSCAP
O comando oscap xccdf eval avalia um host em execução ou uma imagem offline com base em um perfil do SCAP Security Guide e gera um relatório legível; revisar o script de remediação gerado antes de executá-lo evita que uma verificação automatizada acabe causando uma indisponibilidade automatizada.
Legível por máquina: JSON