0
0
Que diferença faz dois anos. Nessa época de 2021, o termo “SBOM” — que significa lista de materiais de software — era pouco comum, mesmo em conversas de segurança. Agora, vemos isso discutido em organizações de todo o país, até mesmo ao redor do mundo.
Isso se deve à Ordem Executiva 14028, assinada pelo presidente Biden em 12 de maio de 2021, um marco crítico no cenário de segurança cibernética do país. O principal objetivo da EO 14028 era estabelecer pré-requisitos de segurança para fornecedores de software que vendem seu software para o governo dos Estados Unidos, mas inevitavelmente as recomendações feitas na ordem também persuadiram o setor privado a tomar conhecimento. Dois anos se passaram desde o anúncio, e vale a pena avaliar onde estamos agora e onde ainda temos melhorias a fazer.
Muitas vezes descrito como uma “lista de ingredientes” para software, um SBOM é uma lista de componentes e suas versões usadas em um aplicativo ou sistema de software. Ele fornece transparência na cadeia de suprimentos de software e ajuda as organizações a gerenciar o risco associado ao software que usam. A ordem executiva determina que os contratados federais mantenham um SBOM para trabalhar com o governo dos EUA. No entanto, agora estamos vendo SBOMs usados muito mais amplamente do que isso.
A conscientização sobre os SBOMs tem crescido tremendamente. Quanto? Números exatos são difíceis de encontrar, mas uma pesquisa com 412 organizações em todo o mundo, realizada em 2022 pela Linux Foundation, conclui:
- 82% estão familiarizados com o termo “lista de materiais de software”.
- 76% estão ativamente engajados em atender às necessidades de SBOM.
- 47% estão produzindo ou consumindo SBOMs.
- 78% das organizações esperam produzir ou consumir SBOMs em 2022, um aumento de 66% em relação ao ano anterior.
O estado do SBOM é este: tornou-se uma ferramenta importante para as organizações agregarem muitos tipos de risco de dependência de software, desde problemas de licenciamento até vulnerabilidades e riscos de fim de vida. A visibilidade que ele proporciona é inestimável, e é por isso que estamos vendo mais organizações do setor privado exigindo que seus parceiros mantenham um SBOM. E por que muitas empresas da Fortune 1000 agora têm um projeto SBOM ativo.
No entanto, com mais adoção, também estamos vendo mais desafios operacionais. A curva de aprendizado tem sido íngreme para algumas organizações. Os líderes de segurança têm dúvidas, como manter, compartilhar, operacionalizar e manter um SBOM atualizado. Operacionalizar o SBOM é o espantalho, e muitas organizações ainda lutam por onde começar com os requisitos básicos para a construção de um SBOM.
Onde a borracha bate na estrada: operacionalizando os SBOMs dois anos depois
O primeiro passo na implementação de um SBOM é definir seu escopo. Entenda onde seus aplicativos críticos estão localizados e o melhor lugar para começar a analisá-los (em desenvolvimento, estágio ou produção). Em seguida, é essencial instrumentar um processo para digitalizar e coletar dados automaticamente. Você não quer digitalizar de vez em quando, manualmente. A visibilidade e as informações atualizadas são fundamentais para garantir que o SBOM forneça informações úteis.
O próximo passo é enriquecer o SBOM com dados como vulnerabilidades e exposições comuns (CVEs), licenças, indicadores de comprometimento (IOCs), reputação e outros fatores que fornecem visibilidade sobre o risco. Correlacionar dados de SBOM com dados de ameaças ajuda as organizações a identificar riscos e priorizar os esforços de correção.
Quais são os desafios das SBOMs?
Dois anos depois, vemos mais organizações usando SBOMs para visibilidade e informações — e também para gerenciamento de vulnerabilidades. Isso inclui a remediação e priorização de falhas no ambiente. Isso pode ser desafiador, pois requer uma compreensão profunda do que é realmente usado em tempo de execução (versus o que pode ser despriorizado). Além disso, as organizações precisam entender as dependências entre os componentes e como elas afetam o aplicativo ou sistema de software. Plataformas completas de cadeia de suprimentos de software precisam fornecer esses recursos para permitir que seus clientes priorizem os esforços de correção.
A automação é outra consideração à medida que vemos mais organização avançando com os SBOMs. Criar SBOMs, mapear o risco para componentes, priorizar e remediar não pode ser feito manualmente na escala e velocidade em que os produtos são desenvolvidos hoje. Os SBOMs simplesmente não podem ser usados operacionalmente se não estiverem acoplados à automação.
O SBOM tornou-se uma ferramenta essencial para gerenciar o risco da cadeia de suprimentos de software. Vimos um crescimento significativo na conscientização e adoção do SBOM nos últimos dois anos. E daqui a dois anos, prevejo que veremos SBOMs usados como padrão por quase todas as organizações que levam a sério sua estratégia de segurança. Ao fazer isso, as organizações podem gerenciar os riscos associados ao software que usam, proteger sua reputação e melhorar sua postura de segurança cibernética.
FONTE: DARK READING