Estrutura de SDLC Secure da OPSWAT:Um Compromisso com a Resiliência e a Segurança de Defesa em Profundidade

Os agentes maliciosos visam os sistemas com fins lucrativos ou de perturbação, provocando custos, riscos comerciais e danos à reputação das organizações. 

De acordo com um inquérito recente, o custo da correção de um erro de segurança é 30 vezes mais elevado quando descoberto em produção do que durante a fase de análise e requisitos.

O Secure SDLC Framework da OPSWATdefine metodologias estruturadas e princípios de segurança que orientam o desenvolvimento seguro de software. 

OPSWAT segue o ciclo de vida de desenvolvimento Software ágil. A fim de cumprir plenamente os requisitos dos nossos clientes, adoptámos o Secure SDLC Framework em função dos requisitos regulamentares e das normas internacionais. Esta abordagem reforça o nosso compromisso com a melhoria contínua e a resiliência num cenário de cibersegurança em evolução.

O Secure SDLC Framework do OPSWATbaseia-se no NIST SP 800-218 SSDFSecure Software Development Framework), garantindo que a segurança é estruturada, mensurável e aplicada de forma consistente em todas as fases do processo de desenvolvimento de software.  

Ao integrar as melhores práticas de SSDF, OPSWAT mantém uma postura de segurança proactiva, integrando a segurança em todas as fases do desenvolvimento de software - desde o planeamento e conceção até à implementação, verificação e monitorização contínua. 

O atestado de conformidade de produtos individuais é fornecido aos nossos clientes do Governo Federal dos EUA a pedido. Consulte os detalhes de contacto abaixo.

À medida que os regulamentos de cibersegurança continuam a evoluir, OPSWAT continua empenhada em alinhar a sua estrutura Secure SDLC com os requisitos regulamentares globais, começando com a Lei de Ciber-resiliência da UE e a Diretiva NIS2. Ao adaptar-se proactivamente às normas emergentes, OPSWAT garante que o seu Secure SDLC permanece abrangente, em conformidade e resiliente num cenário regulamentar cada vez mais complexo.

A manutenção de uma segurança de informação robusta é fundamental para a integridade operacional e a conformidade regulamentar. O Secure SDLC Framework da OPSWAT incorpora os princípios do ISMS (Sistema de Gestão de Segurança da Informação) ISO 27001, assegurando que os controlos de segurança, as estratégias de gestão de riscos e as medidas de conformidade são perfeitamente integrados no funcionamento dos nossos produtos na nuvem. 

Como fornecedor e consumidor das nossas soluções de segurança, OPSWAT aplica políticas de segurança internas da empresa, garantindo que os nossos produtos certificados cumprem as expectativas de segurança de nível empresarial antes da implementação.  

Ver mais detalhes em Conformidade e certificações.

Para garantir os mais elevados padrões de qualidade de software, o Secure SDLC Framework da OPSWATestá integrado no ISO 9001 QMS (Sistema de Gestão da Qualidade). O QMS estabelece controlos de qualidade auditados para a governação, gestão de alterações e processos multifuncionais, apoiando a definição, conceção, desenvolvimento, produção e manutenção das ofertas de produtos e de apoio, estendendo-se para além da I&D a áreas como as vendas, apoio ao cliente, tecnologia da informação e recursos humanos.  

Esta abordagem reforça o nosso compromisso com uma abordagem estruturada e baseada no risco para a gestão da qualidade, assegurando que a segurança das aplicações continua a ser uma consideração integral em todas as funções empresariais.

Ver mais detalhes em Conformidade e certificações.

O OWASP Software Assurance Maturity Model (SAMM) é uma estrutura abrangente concebida para ajudar as organizações a avaliar, formular e implementar estratégias eficazes de segurança de software no âmbito do seu atual SDLC.

Sendo uma estrutura de código aberto, o SAMM beneficia de contribuições globais, garantindo uma abordagem colaborativa e em constante evolução à segurança das aplicações. A sua metodologia estruturada permite às organizações uma forma eficaz e mensurável de analisar e melhorar o seu ciclo de vida de desenvolvimento. O SAMM suporta o ciclo de vida completo do desenvolvimento. A SAMM é agnóstica em termos de tecnologia e processos. A SAMM é evolutiva e orientada para o risco. Ao tirar partido da SAMM, as equipas obtêm informações práticas sobre as lacunas de segurança e podem melhorar sistematicamente a sua postura de segurança ao longo do ciclo de vida do desenvolvimento.

O OWASP Application Security Verification Standard (ASVS) é uma estrutura reconhecida mundialmente, concebida para estabelecer uma abordagem estruturada, mensurável e acionável à segurança das aplicações Web. Fornece aos programadores e às equipas de segurança um conjunto abrangente de requisitos de segurança e diretrizes de verificação para garantir que as aplicações cumprem as melhores práticas da indústria. 

Sendo uma estrutura de código aberto, o ASVS beneficia de amplas contribuições da comunidade de segurança global, garantindo que se mantém atualizado em relação às ameaças emergentes e à evolução das normas de segurança.

O Programa Secure SDLC da OPSWAT traduz a Estrutura Secure SDLC em governação estruturada, assegurando que os requisitos de segurança são documentados, mantidos, medidos e continuamente melhorados, garantindo também que todas as partes envolvidas recebem formação adequada. Estabelece funções, responsabilidades e medidas de segurança para os ambientes de desenvolvimento, teste e produção, bem como para a segurança das condutas, definindo o Ambiente de Desenvolvimento Secure e obrigando à aplicação de políticas de segurança no âmbito do Processo SDLC Secure .

Gestão de alto nível - Diretor de Produtos (CPO)

O Diretor de Produtos (CPO) é responsável pela supervisão estratégica e pela aplicação do Programa Secure SDLC em todas as equipas de produtos, bem como noutros programas de Investigação e Desenvolvimento (I&D), como o Programa de Garantia de Qualidade (QA) e o Programa de Experiência do Utilizador (UX), garantindo uma abordagem coesa ao desenvolvimento de software seguro, de alta qualidade e centrado no utilizador.

Como principal responsável pelos riscos de todos os produtos e processos de I&D, o CPO encarrega as operações de I&D de serem responsáveis pelo programa Secure SDLC e garante que os líderes de produto estão a aplicar o programa Secure SDLC e a implementar o processo Secure SDLC de forma eficaz nas equipas de produto. Nesta função, o CPO aprova a modificação do Programa Secure SDLC e os desvios do Processo Secure SDLC.

O CPO também monitoriza os resultados do programa Secure SDLC, acompanhando a maturidade da segurança, as vulnerabilidades, a conformidade e as actividades de desenvolvimento para manter uma forte postura de segurança dos produtos.

Além disso, o CPO é responsável pela atribuição e aprovação do orçamento de segurança de I&D, assegurando que são dedicados recursos adequados ao programa Secure SDLC.

Prioridades estratégicas

O plano estratégico da OPSWATpara a segurança das aplicações está alinhado com as suas prioridades comerciais e apetência pelo risco, tendo em conta o nível de maturidade de cada produto e a sua exposição a ameaças à segurança. O foco principal é a proteção de produtos de alto risco, particularmente aqueles com uma grande base de clientes, implantações voltadas para o público ou integração em infra-estruturas críticas.

Como parte do programa Secure SDLC, para além das formações gerais de sensibilização para a segurança da empresa, é obrigatória a formação em segurança específica para todos os funcionários envolvidos no desenvolvimento seguro. Todas as formações são registadas nas ferramentas de formação da empresa. Os programas de formação e sensibilização são revistos periodicamente para incorporar novas tendências de segurança e garantir a conformidade contínua com as normas de segurança.

OPSWAT está empenhado em melhorar continuamente o seu programa Secure SDLC através da medição estruturada do desempenho, de avaliações de maturidade e de actualizações regulares para garantir uma eficácia de segurança contínua.  

Para manter uma postura de segurança forte, OPSWAT emprega uma abordagem sistemática para acompanhar e melhorar o desempenho da segurança. Isto inclui avaliações trimestrais da maturidade da segurança dos produtos, análises internas de segurança para verificar a adesão às melhores práticas e a definição de indicadores-chave de desempenho (KPI) anuais, que são medidos trimestralmente.  

Para medir eficazmente a postura de segurança das aplicações, OPSWAT avalia as equipas utilizando métricas estruturadas. A maturidade da segurança do produto é avaliada por equipa com base na estrutura SAMM, fornecendo uma medida quantificável do progresso da segurança. Além disso, os produtos são submetidos a uma avaliação de conformidade ASVS para garantir a adesão aos requisitos de verificação de segurança. A conformidade com o processo Secure SDLC é monitorizada de perto, avaliada e a realização dos objectivos KPI é baseada em provas, garantindo que a postura de segurança e as melhorias de segurança são mensuráveis e acionáveis. Todas as equipas de produtos são obrigadas a cumprir os objectivos de maturidade da segurança como parte da sua avaliação anual de desempenho. 

Como parte dos seus esforços de melhoria contínua, OPSWAT introduz periodicamente novas iniciativas de segurança de produtos para aumentar os níveis de maturidade e reforçar a segurança das aplicações. Estas iniciativas incluem a atualização das políticas de segurança para fazer face a ameaças emergentes, a integração de novas ferramentas de segurança para uma melhor deteção e prevenção e a expansão dos objectivos KPI para impulsionar o progresso contínuo. 

Para reforçar ainda mais a governação em matéria de segurança, OPSWAT efectua uma revisão anual do quadro do Secure SDLC, incorporando as conclusões das análises das causas profundas de incidentes de segurança anteriores, avaliações das tendências em matéria de vulnerabilidade e aperfeiçoamentos dos processos e políticas existentes.  

Esta abordagem estruturada de melhoria contínua garante que OPSWAT mantém uma postura proactiva e resiliente em matéria de segurança dos produtos, adaptando-se eficazmente à evolução dos desafios da cibersegurança, ao mesmo tempo que cumpre os objectivos de segurança regulamentares e operacionais.

O Processo Secure SDLC operacionaliza ainda mais o Programa Secure SDLC, definindo os controlos de segurança que as equipas devem seguir, incluindo actividades específicas, tais como verificações de segurança automatizadas e mecanismos de verificação em cada fase de desenvolvimento. Este processo está alinhado com outros programas-chave de I&D, como o Programa de Garantia de Qualidade e o Programa de Experiência do Utilizador, garantindo uma abordagem coesa ao desenvolvimento de software seguro, de alta qualidade e centrado no cliente. 

O processo Secure SDLC é detalhado nas secções seguintes:

• Conceção Secure e avaliação de riscos
• Implementação, construção e implantação Secure
• Teste e verificação da segurança das aplicações
• Libertação Secure
• Operações e manutenção Secure

O Processo SDLC Secure é um processo de alto nível, as equipas podem implementá-lo de uma forma personalizada e alargada com a condição de que a segurança do processo deve ser mantida ao mesmo nível mínimo. Os desvios ao processo Secure SDLC devem ser documentados e aprovados.

O Programa Secure SDLC inclui várias políticas que devem ser formalmente aprovadas e reconhecidas pelas equipas de produto para garantir a conformidade com os seus requisitos. A adesão a estas políticas é obrigatória internamente e cada equipa é responsável por as rever, assinar e implementar como parte dos seus processos de desenvolvimento. 

Segue-se uma lista das principais políticas, juntamente com os respectivos objectivos. Para as políticas com importância externa, são incorporados pormenores adicionais no presente documento.

Como parte do processo Secure SDLC, os requisitos de segurança são monitorizados, documentados e mantidos ao longo do ciclo de vida do desenvolvimento. Os fornecedores terceiros devem reconhecer e cumprir a ASVS, garantindo a consistência das expectativas de segurança e a adesão à Política de Conformidade com a Privacidade do Produto em todos os componentes de software. 

A segurança é incorporada em todas as fases do ciclo de vida do desenvolvimento. É da responsabilidade dos defensores da segurança ter em mente as expectativas do processo Secure SDLC e representá-las nas suas equipas. 

O conjunto de requisitos de conceção Secure inclui requisitos de segurança funcionais e não funcionais baseados no ASVS. Os modelos de referência são fornecidos pelas operações de I&D para apoiar as decisões de conceção, juntamente com ajustamentos documentados aos requisitos ASVS, se necessário (por exemplo, requisitos de encriptação mais fortes).

A modelação de ameaças é um processo estruturado para identificar ameaças e vulnerabilidades nas fases iniciais do ciclo de vida do desenvolvimento. É uma parte integrante do processo Secure SDLC, conduzido regularmente - pelo menos uma vez por ano ou sempre que são introduzidas novas funcionalidades ou alterações arquitectónicas. As equipas de produtos executam a modelação de ameaças definindo objectivos de segurança, identificando activos e dependências, analisando potenciais cenários de ataque e mitigando as ameaças identificadas.  

Uma abordagem melhorada incorpora a análise do fluxo de dados e as práticas de modelação de ameaças estabelecidas (por exemplo, o modelo STRIDE), assegurando uma avaliação abrangente dos produtos. Quando necessário, são iniciadas revisões de segurança para validar a conformidade com os requisitos de segurança e abordar proactivamente os riscos potenciais. As decisões de conceção são cuidadosamente documentadas e quaisquer riscos remanescentes são continuamente monitorizados ao longo do ciclo de vida do produto.

Os riscos de segurança das aplicações são avaliados através de várias fontes, incluindo ameaças residuais identificadas durante a modelação de ameaças, vulnerabilidades de segurança amplamente reconhecidas, como as que constam do Top 10 da OWASP e do Top 25 da SANS, e controlos de segurança em falta baseados nas diretrizes ASVS. Outros factores de risco incluem deficiências na gestão de segredos ao longo dos processos de criação, implementação e lançamento, bem como vulnerabilidades em componentes de código aberto e de terceiros. 

Na sequência da avaliação dos riscos, são desenvolvidos planos de atenuação para reduzir a gravidade dos riscos identificados, tendo em conta tanto o impacto como a probabilidade. Estes planos, juntamente com os riscos correspondentes e as etapas de atenuação, são cuidadosamente documentados. 

Os riscos residuais são monitorizados ao longo do ciclo de vida do produto e sujeitos a revisão periódica, devendo ser formalmente reconhecidos pelos proprietários do risco. Também são incorporados nos relatórios internos de lançamento para manter a visibilidade e a responsabilidade. 

Quando necessário, são iniciadas revisões de segurança para garantir a conformidade com os requisitos de segurança e para abordar proactivamente os riscos potenciais, reforçando a postura global de segurança do produto.

Como parte do processo SDLC Secure , incluindo a implementação, a construção e a implantação, o objetivo é evitar vulnerabilidades e falhas, com base na conceção Secure e na avaliação dos riscos. O conjunto de requisitos contém expectativas sobre requisitos de segurança funcionais e não funcionais baseados no ASVS, desenvolvimento seguro e metodologia de teste baseada no ambiente de desenvolvimento Secure .  

Durante a implementação, devem ser aplicadas as melhores práticas de codificação Secure , a revisão do código Secure e a deteção precoce de falhas de segurança. As equipas devem aderir à Política de Segurança Supply Chain (incluindo a integração de fornecedores e tópicos de software de código aberto), à Política de Utilização de IA e à Política de Tratamento de Amostras de Malware. Durante a construção e a implantação, são necessárias a construção e a implantação Secure com o uso centralizado do pipeline CI / CD e a separação de funções.

As equipas de produtos devem seguir as melhores práticas de codificação segura independentes da língua durante a implementação. Devem validar os dados de entrada, higienizar os dados enviados para outros sistemas, eliminar os avisos do compilador, definir mensagens de erro seguras, aplicar a codificação de saída quando aplicável, implementar o registo seguro sem expor dados sensíveis e seguir as diretrizes adequadas de tratamento de erros e gestão de excepções. As equipas devem também garantir que a criptografia, se utilizada, se baseia em algoritmos aprovados e na geração segura de números aleatórios, e gerir de forma segura os recursos do sistema, tratando a memória com segurança, prevenindo condições de corrida e evitando bloqueios através de uma sincronização adequada. 

As equipas de produto também são aconselhadas a seguir as diretrizes de codificação segura específicas da língua, aplicadas pelas ferramentas SAST, como exemplificado abaixo: 

Para Java, as equipas devem garantir que as chaves utilizadas nas operações de comparação são imutáveis, utilizar SecureRandom em vez de Random e evitar a desserialização insegura através da validação ou restrição das classes de entrada.

Em C++, recomenda-se a deteção e o tratamento de erros de atribuição de memória, a prevenção de transbordos de memória intermédia através da verificação dos limites e da utilização de ponteiros inteligentes, como std::unique_ptr(), e a prevenção de funções não seguras, como strcpy() e sprintf(). 

Para Python, os programadores devem evitar utilizar funções como eval() ou exec() para mitigar os riscos de injeção de código e preferir formatos de serialização seguros, como o módulo json, em vez de pickle quando processam dados não confiáveis.

Como parte das revisões de segurança exigidas pela política de verificação da segurança das aplicações, a revisão do código seguro é importante e é executada em função da tecnologia de desenvolvimento, sendo aplicadas várias listas de verificação da revisão do código Secure com base na sérieOWASP Cheatsheet.

Conforme exigido pela Política de verificação de segurança de aplicações, a deteção precoce de falhas de segurança é um componente crítico do processo de desenvolvimento. Para minimizar potenciais problemas de segurança, é obrigatória uma abordagem "fail to build", garantindo que o código inseguro não avança através do pipeline. Além disso, é aplicada uma abordagem de "falha na fusão", exigindo que as equipas corrijam quaisquer problemas detectados antes de as alterações poderem ser integradas. A resolução das falhas detectadas é essencial para cumprir os critérios de lançamento.

Como parte do processo Secure SDLC, o uso de um pipeline CI/CD centralizado e orquestrado é obrigatório para impor compilações seguras e evitar ataques à cadeia de suprimentos. Os registos de auditoria, compilação e implementação são gerados, preservados e revistos conforme definido nas políticas de segurança da empresa. 

Cada equipa de produto é responsável por seguir configurações seguras de compilação e compilador, quando aplicável. Têm de utilizar opções de compilador seguras, desativar o código de depuração, reforçar os tempos de execução para linguagens interpretadas, fixar versões de dependências, garantir compilações reproduzíveis e reforçar imagens de contentores. As configurações utilizadas devem ser documentadas e revistas periodicamente. 

Em consonância com o princípio da Separação de Funções, os programadores e outros membros da equipa que tenham acesso ao código ou à compilação não podem ter acesso ao ambiente de produção. No caso de produtos na nuvem, apenas os engenheiros de fiabilidade do site do produto podem implementar no ambiente de produção.

De acordo com a nossa Política de Verificação de Segurança de Aplicações, implementamos documentação formal e rastreio para problemas descobertos e atribuímos ferramentas automatizadas para verificação contínua. Como parte do processo Secure SDLC, as verificações de segurança são aplicadas e acompanhadas em todas as fases do SDLC para cumprir os requisitos de conformidade. O objetivo destas verificações é encontrar eficazmente as possíveis falhas de segurança. As questões de segurança que surgem são investigadas pelas equipas e tratadas dentro dos prazos estabelecidos. Os prazos fazem parte dos KPIs de segurança definidos.

• Revisões de arquitetura e design: Os engenheiros seniores e os membros da Equipa Virtual de Segurança das Aplicações avaliam os aspectos de segurança nas alterações de conceção, incluindo encriptação, autenticação, autorização, auditoria, reforço do sistema, arquitetura do sistema e da rede. 
• Revisões de código: para além das revisões de código regulares efectuadas por engenheiros pares e seniores, os membros da Equipa Virtual de Segurança das Aplicações analisam as alterações para evitar falhas comuns, como injeção, tratamento de erros e configurações inseguras.

• Verificação de segredos para evitar a exfiltração de segredos e garantir uma boa conceção e implementação segura do tratamento de segredos.
• Ferramentas SAST (Static Application Security Testing) para detetar vulnerabilidades (por exemplo, injeção de SQL, excessos de tampão).
• A SCA (Software Composition Analysis) é utilizada para detetar vulnerabilidades de código aberto.
• O DAST (Dynamic Application Security Testing) é utilizado para detetar problemas de tempo de execução (por exemplo, falhas de memória) e de ambiente

As ferramentas definidas na secção Deteção precoce de problemas de segurança são de utilização obrigatória no pipeline de CI/CD. Todas as vulnerabilidades identificadas devem ser corrigidas de acordo com a Política de Vulnerability Management do Produto.

As metodologias de testes de segurança automatizados e manuais são utilizadas em conformidade com o programa de garantia de qualidade que executa o plano de testes de segurança.

• As ferramentas DAST são utilizadas para detetar vulnerabilidades em tempo de execução, testar configurações predefinidas e testar a resiliência do sistema após a aplicação das sugestões de reforço. Os testes visam tanto o software como a infraestrutura subjacente. 
• Para evitar regressões nos requisitos e caraterísticas de segurança, utilizamos ferramentas de teste automatizadas para verificar continuamente a integridade das caraterísticas e controlos de segurança. 
• Os testes manuais são aplicados nos casos em que as ferramentas automatizadas são insuficientes, como na verificação dos controlos de fuga de informação, na identificação de falhas na lógica empresarial e de vulnerabilidades contextuais. 
• A verificação automática de malware de artefactos no ciclo de vida do desenvolvimento também faz parte das etapas que se centram na prevenção de problemas de segurança.

Como parte do processo Secure SDLC, o processo de lançamento impõe critérios de lançamento que garantem a adesão ao processo Secure SDLC e a segurança geral do produto, com base nos resultados dos testes e da verificação da segurança das aplicações. O controlo de versões do produto desempenha um papel crucial na manutenção das melhorias de segurança em todas as versões, evitando a regressão relacionada com a segurança e preservando a postura de segurança alcançada, como um requisito fundamental para cada versão. 

O processo de lançamento inclui a geração de relatórios internos de lançamento, que documentam os riscos residuais e quaisquer questões de segurança pendentes. Estes relatórios devem ser formalmente aprovados pelo líder do produto. Além disso, as notas de lançamento externas comunicam as alterações e correcções relacionadas com a segurança como parte do lançamento oficial do produto. 

Para produtos em nuvem, a implantação segue uma abordagem de automação "fail to deploy", garantindo que apenas compilações seguras sejam liberadas. O teste e a verificação da segurança das aplicações estão integrados no pipeline de implementação, com uma estratégia operacional de "pull" em vez de "push", reforçando a validação da segurança antes da implementação da produção. 

De acordo com a Política de Gestão de SBOM, cada versão inclui umaBill of Materials (SBOM) Software Bill of Materials (SBOM) para manter a rastreabilidade da proveniência dos componentes, apoiando a transparência e a segurança da cadeia de fornecimento. Todos os ficheiros de lançamento necessários são arquivados de forma segura para garantir a acessibilidade a longo prazo.

De acordo com a Política de Integridade de Lançamentos, para manter a integridade e a segurança dos lançamentos de produtos, é aplicado um sistema de versionamento estruturado (por exemplo, Versionamento Semântico), garantindo uma rastreabilidade clara das alterações e um período de retenção definido para todos os artefactos lançados, incluindo a documentação. Para aumentar ainda mais a segurança, os artefactos de software são assinados digitalmente com o nome da empresa, com impressões digitais SHA publicadas que permitem aos utilizadores verificar a autenticidade e detetar quaisquer tentativas de adulteração. 

A documentação versionada acompanha cada versão, fornecendo orientações detalhadas sobre métodos de verificação de integridade, procedimentos de instalação segura, melhores práticas de configuração e medidas de reforço do sistema. Estes recursos ajudam os utilizadores a implementar controlos de segurança de forma eficaz, reduzindo potenciais superfícies de ataque. Além disso, o Contrato de Licença do Utilizador Final (EULA) está incluído para estabelecer obrigações de conformidade e manter a transparência legal. 

O SBOM para produtos individuais é fornecido aos nossos clientes a pedido. Contacte-nos.

Os ambientes de desenvolvimento, teste e produção são separados de forma segura para evitar o acesso não autorizado. Cada ambiente segue linhas de base de endurecimento rigorosas e protocolos de segurança de ponto final. Os ambientes de desenvolvimento devem estar em conformidade com as políticas de segurança da empresa.

Como parte da proteção dos pontos terminais, todos os dispositivos pertencentes à OPSWAT são monitorizados quanto a vulnerabilidades, software instalado, correcções instaladas e conformidade com as políticas de segurança da empresa. Em caso de não conformidade, são tomadas medidas restritivas para limitar o acesso aos recursos da empresa. 

Os recursos classificados com a categoria de risco elevado só podem ser acedidos através de vias de acesso controladas (VPN). Os dispositivos fora da rede da empresa são obrigados a utilizar canais seguros para aceder aos recursos de I&D.

A segurança do pipeline de CI/CD segue diretivas de segurança rigorosas para mitigar as ameaças em evolução. A fonte das ameaças pode ser elementos de infraestrutura desactualizados (como sistemas operativos, ferramentas de análise, etc.), acessos não autorizados devido a controlos de privilégios fracos e ambientes pouco isolados. Manter a infraestrutura de CI/CD actualizada, cuidadosamente examinada e rigorosamente controlada é uma pedra angular do nosso SDLC seguro. 

Regionalmente, são utilizados servidores baseados nos EUA para todos os serviços centralizados, incluindo armazenamento de código, o pipeline CI/CD, ferramentas de análise e teste e assinatura segura de artefactos. A configuração de todas as ferramentas centralizadas está sob o controlo das Operações de I&D. 

Aplicamos mecanismos de autenticação fortes (autenticação multifactor - MFA) e controlos de autorização (controlo de acesso baseado em funções - RBAC). São efectuadas análises de acesso regulares e com privilégios mínimos. 

Os nossos pipelines incorporam várias ferramentas de análise e automatização de testes, incluindo Testes Estáticos de Segurança de Aplicações (SAST), Análise de Composição Software (SCA), Testes Dinâmicos de Segurança de Aplicações (DAST), Verificação de Segredos e Verificação de Malware. 

Na nossa solução de assinatura de código seguro, utilizamos módulos de segurança Hardware (HSMs) para proteger o material chave contra acesso não autorizado e para gerar a assinatura. A solução de assinatura faz parte da infraestrutura de CI/CD, mas a segmentação da rede está em vigor. Apenas as operações de I&D estão autorizadas a aceder aos HSMs por períodos curtos. Todas as acções de assinatura são registadas e podem ser revistas durante uma pista de auditoria. 

O conjunto de ferramentas utilizado para construir, compilar ou testar o software deve ter informações de proveniência e provir de uma fonte validada. As ferramentas utilizadas no pipeline de CI/CD são limitadas em número; apenas as ferramentas necessárias são instaladas. Apenas o software LTS é permitido para as etapas de compilação e construção no pipeline. Na operação dos serviços centralizados, são definidos períodos regulares de manutenção e rotação de chaves. As ferramentas desenvolvidas internamente são abrangidas pelo processo Secure SDLC.

O reforço do ambiente para todos os serviços centralizados é contínuo e estes requisitos de segurança são revistos periodicamente. As orientações de reforço são comunicadas às equipas de produtos para garantir que estão preparadas e podem adaptar os seus processos de desenvolvimento em conformidade. No caso de um incidente de segurança, é realizada uma RCA para tomar medidas preventivas e atualizar estes requisitos.

A proteção do código-fonte é uma parte crucial do desenvolvimento de software para garantir a confidencialidade e a integridade do código-fonte dentro da empresa. 

O código-fonte é armazenado de acordo com o princípio do menor privilégio, permitindo o acesso apenas a pessoal e ferramentas autorizados. O código-fonte está sob controlo de versões. O sistema de gestão do controlo de versões garante a rastreabilidade e a responsabilidade das alterações ao código. Os armazenamentos de código-fonte são encriptados com criptografia compatível com FIPS 140-3 e protegidos com um comprimento de chave adequado.

O cumprimento desta política é obrigatório para todas as equipas internas. Este documento está subordinado às políticas da empresa, o que significa que, em caso de contradição, as políticas da empresa têm precedência e devem ser seguidas. 

Processo de escalonamento para violações do Secure SDLC: Quaisquer violações desta política são tratadas internamente, começando pelas Operações de I&D e subindo até ao Diretor de Produtos (CPO), conforme necessário.

Espera-se que os fornecedores que fornecem componentes ou serviços para produtos no âmbito da ISO 27001, SOC2, NIST SSDF cumpram os requisitos abaixo descritos do Secure SDLC Framework. A conformidade está sujeita a auditorias de segurança periódicas, avaliações de terceiros e obrigações de cada parte ao abrigo de contratos executados. 

Todos os fornecedores são obrigados a fornecer informações sobre a proveniência e a integridade, juntamente com documentação de apoio, tal como definido na secção Integridade da versão. 

Os fornecedores de componentes e bibliotecas de produtos devem estabelecer ambientes de desenvolvimento alinhados com as nossas práticas, conforme descrito na secção Ambiente de desenvolvimento Secure . Têm de aplicar testes de segurança aos seus componentes e bibliotecas, conforme descrito na secção Teste e verificação da segurança das aplicações. 

Os fornecedores de componentes do gasoduto também devem estabelecer ambientes de desenvolvimento alinhados com as nossas práticas, tal como descrito na secção Ambiente de desenvolvimento Secure . Além disso, os seus processos de desenvolvimento devem estar em conformidade com o processo Secure SDLC da OPSWAT. 

Espera-se que os fornecedores de serviços utilizem ambientes baseados nos EUA que ofereçam uma postura de segurança comparável à dos serviços da OPSWAT. O seu Secure SDLC deve incluir um programa Secure SDLC e um processo Secure SDLC que reflictam as expectativas da OPSWAT.