Vendendo software para o governo dos EUA? Conheça o atestado de segurança primeiro

Nos últimos meses, o governo dos EUA introduziu vários novos requisitos que afetam as organizações que vendem software para agências governamentais. Como esses novos requisitos são complexos, muitos líderes ainda não têm certeza de como sua organização será impactada. Neste artigo, compartilharei alguns dos conceitos mais importantes que você precisará entender para proteger seus negócios governamentais e manter a conformidade.

Novos requisitos de segurança de software: o que mudou?

Nos últimos anos, incidentes de segurança de alto nível, como os que afetaram SolarWinds e o pacote de código aberto log4j têm aumentado a atenção do governo na segurança de software. Começando com Ordem Executiva da Casa Branca 14028 sobre a melhoria da segurança cibernética do país em maio de 2021, uma série de ações nos últimos dois anos levou a um conjunto de requisitos claros que afetam qualquer fornecedor de software do governo.

Daqui para frente, qualquer organização que venda software para o governo dos EUA será obrigada a atestar que está em conformidade com as práticas seguras de desenvolvimento de software descritas pelo governo no Estrutura de desenvolvimento de software seguro NIST.

Uma das coisas mais importantes a entender é que as organizações não devem simplesmente atestar que seguem essas práticas para o código de software que escrevem, mas também que os componentes de software livre que inserem em seus aplicativos também seguem essas práticas.

No início de junho, o governo reafirmou essas exigências em Memorando OMB M-23-16 (PDF) e definir prazos de conformidade que estão se aproximando rapidamente - provavelmente chegarão no quarto trimestre deste ano (para software crítico) e no primeiro trimestre do próximo ano (para todos os outros softwares).

Isso significa que, nos próximos meses, as organizações se esforçarão para entender esses novos requisitos de atestado e determinar como sua organização cumprirá, tanto para o código que elas mesmas escrevem quanto para os componentes de código aberto que trazem para seus produtos de software.

De acordo com M-23-16, a penalidade por descumprimento é severa:

“O órgão [federal] deve interromper o uso do software se a agência considerar a documentação do produtor de software insatisfatória ou se a agência não puder confirmar que o produtor identificou as práticas que não pode atestar…”

Caso Particularmente Desafiador de Código Aberto

Como muitas organizações estão se aprofundando nos requisitos de certificação, elas estão descobrindo que a conformidade, especialmente em prazos apertados, pode ser um desafio. O NIST SSDF é uma estrutura complexa de segurança e levará tempo para as organizações não apenas garantirem a conformidade com essas práticas, mas também documentarem suas práticas em detalhes.

Mas ainda mais assustador é que o governo está pedindo aos fornecedores que atestem as práticas de segurança de todo o seu produto de software, que inclui os componentes de código aberto desse software. Hoje, o software moderno geralmente é composto em grande parte de componentes de código aberto que foram montados juntos, junto com algum software personalizado. Em nossa pesquisa, descobrimos que mais de 90% dos aplicativos contêm componentes de código aberto, e em muitos casos código aberto compõe mais de 70% da base de código.

Sua organização pode atestar suas próprias práticas de segurança, mas como exatamente você pode atestar as práticas de segurança seguidas pelos mantenedores de software livre que escrevem e mantêm o código-fonte aberto que você usa em seus aplicativos?

É um grande desafio e as organizações procuram mantenedores de código aberto para obter mais informações sobre suas práticas de segurança. Infelizmente, muitos desses mantenedores de código aberto são voluntários não remunerados, que trabalham em código aberto como hobby à noite e nos fins de semana. Portanto, pedir que eles façam o trabalho extra para validar que suas práticas de segurança correspondem aos altos padrões definidos pelo NIST SSDF não é prático.

Uma maneira pela qual as organizações podem evitar esse desafio é simplesmente não usar código aberto em seus aplicativos. E, embora pareça uma solução simples à primeira vista, também é uma alternativa cada vez mais inviável, já que o código aberto de várias maneiras se tornou a plataforma de desenvolvimento moderna de fato.

Uma maneira melhor de resolver esse problema é garantir que os mantenedores dos pacotes nos quais você confia sejam pagos para fazer esse importante trabalho de segurança.

Isso pode exigir que você faça pesquisas extras para garantir que os componentes de código aberto que você está usando tenham mantenedores por trás deles que estão sendo pagos - seja por benfeitores corporativos, por fundações ou por esforços comerciais - para validar que seus pacotes atendam a esses importantes padrões de segurança. Ou você mesmo pode entrar em contato com os mantenedores e se tornar um patrocinador corporativo do trabalho deles. Ao projetar sua abordagem, lembre-se de que a maioria dos aplicativos modernos não triviais tem milhares de dependências distintas de software livre, cada uma criada e mantida por um indivíduo ou equipe diferente, portanto, o esforço manual para dimensionar essa abordagem é considerável.

Um passo em frente desafiador, mas necessário

Esses requisitos podem ser difíceis de cumprir, mas no contexto de crescentes vulnerabilidades de segurança que causam danos maciços aos setores público e privado, eles são um passo necessário à frente. O governo dos Estados Unidos é o maior comprador de bens e serviços do mundo, e isso vale tanto para TI quanto para outros domínios. Ao usar seu poder de compra para forçar melhorias no padrão geral de segurança para software, o governo está ajudando a garantir um futuro mais seguro.

• Conteúdo com tecnologia de SEO e distribuição de relações públicas. Seja amplificado hoje.
• PlatoData.Network Gerativa Vertical Ai. Capacite-se. Acesse aqui.
• PlatoAiStream. Inteligência Web3. Conhecimento Amplificado. Acesse aqui.
• PlatãoESG. Automotivo / EVs, Carbono Tecnologia Limpa, Energia, Ambiente, Solar, Gestão de resíduos. Acesse aqui.
• BlockOffsets. Modernizando a Propriedade de Compensação Ambiental. Acesse aqui.
• Fonte: https://www.darkreading.com/application-security/selling-software-government-know-security-attestation-first