A Open Source Security Foundation (OpenSSF) lançou o Security Baseline de Projeto, uma iniciativa para auxiliar projetos de código aberto de todos os portes a fortalecerem suas práticas de segurança. Essa baseline define um conjunto mínimo de requisitos de segurança para aplicações, permitindo que desenvolvedores implementem medidas eficazes para proteger a integridade, confidencialidade e disponibilidade de seus projetos. O objetivo é garantir que, desde o início, a segurança seja uma prioridade no desenvolvimento de softwares.
O que é o Security Baseline de Projeto?
O Security Baseline de projeto estabelece um conjunto de práticas de segurança que os desenvolvedores podem seguir para garantir o desenvolvimento seguro de softwares. Isso inclui a configuração adequada de ferramentas e infraestrutura para proteger a integridade, confidencialidade e disponibilidade do trabalho. A iniciativa visa fornecer um ponto de partida claro e acessível para projetos de todos os tamanhos, desde pequenos projetos individuais até grandes iniciativas como Kubernetes e OpenStack.
Chris “CRob” Robinson, arquiteto-chefe de segurança da OpenSSF, explicou que a baseline é dividida em três níveis, dependendo do número de contribuidores e mantenedores do projeto. Ele destaca que existem projetos com equipes de segurança robustas, um nível intermediário com projetos que possuem entre 2 e 100 mantenedores, e uma grande quantidade de projetos com apenas um mantenedor. Essa divisão permite que a baseline seja adaptada às necessidades específicas de cada projeto.
Muitas vezes, desenvolvedores buscam soluções prontas na internet e as integram em operações empresariais ou produtos comerciais sem avaliar os riscos envolvidos. O Security Baseline de projeto busca mitigar esse problema, oferecendo um conjunto de diretrizes que ajudam a garantir que o código utilizado seja seguro e confiável, minimizando vulnerabilidades e potenciais explorações.
Para facilitar a adoção, a OpenSSF criou uma tabela de соответствия. Robinson explica que, se um fabricante ou empresa seguir o framework de segurança cibernética do NIST ou tiver obrigações regulatórias, a baseline pode ser mapeada para esses regimes e frameworks. Isso demonstra que seguir as práticas da baseline pode ajudar a cumprir requisitos de auditoria e regulamentação, comprovando a diligência na segurança do software.
Níveis de Maturidade do Security Baseline de Projeto
Cada nível do modelo de maturidade do Security Baseline de projeto lista requisitos para um conjunto mínimo de exigências de segurança, abrangendo áreas como controle de acesso, construção e lançamento, documentação, governança, aspectos legais, qualidade, avaliação de segurança e tratamento de vulnerabilidades. Essa estrutura permite que os projetos evoluam gradualmente em suas práticas de segurança.
Como exemplo, no controle de acesso, o Nível de Maturidade 1 exige autenticação multifator para acesso ao sistema de controle de versão. O Nível 2 inclui essa exigência e adiciona que, ao atribuir permissões em um CI/CD pipeline, o código fonte ou configuração deve conceder apenas os privilégios mínimos necessários para a atividade. Já o Nível 3 inclui regras para commits e exclusões do ramo de código principal. Cada nível de maturidade oferece um conjunto crescente de proteções.
Robinson acrescenta que a OpenSSF oferece orientação sobre como cada perfil se encaixa nos diferentes níveis de maturidade. O próximo passo é fornecer mais referências e documentação para que as pessoas possam obter informações e entender melhor os conceitos. Ele observa que termos técnicos como “privilégio mínimo” podem não ser compreendidos por todos os desenvolvedores, e a OpenSSF busca fornecer o contexto necessário.
É fundamental que os consumidores de software de código aberto compreendam que a maioria dos mantenedores de projetos não são profissionais de segurança cibernética. Eles doam seu tempo e conhecimento, e muitas vezes não são pagos para isso. Robinson enfatiza que esses mantenedores “não são seus funcionários e você realmente não pode fazer exigências” a eles. Para muitos, garantir a segurança do código é algo secundário.
Robinson mencionou que a vulnerabilidade do Log4Shell levou empresas a ameaçarem ações legais contra os mantenedores, exigindo correções. No entanto, a maioria das licenças de software de código aberto são fornecidas sem garantia ou suporte. Ele espera que o Security Baseline de projeto incentive boas práticas na comunidade de desenvolvimento e dê aos mantenedores a capacidade de se defenderem quando forem cobrados por empresas que não entendem as limitações do modelo de código aberto.
Este conteúdo foi auxiliado por Inteligência Artificial, mas escrito e revisado por um humano.