Estrutura Secure OPSWAT:
Um compromisso com a resiliência e a segurança 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 Quadro de Trabalho Secure OPSWATdefine metodologias estruturadas e princípios de segurança que orientam o desenvolvimento seguro de software. 

OPSWAT o Ciclo de Vida Software Ágil. Para garantir a total conformidade com os requisitos dos nossos clientes, adaptámos o Quadro Secure aos requisitos regulamentares e às normas internacionais. Esta abordagem reforça o nosso compromisso com a melhoria contínua e a resiliência num panorama de cibersegurança em constante evolução.

A Estrutura Secure OPSWATbaseia-se na norma NIST SP 800-218 SSDF (EstruturaSoftware Secure Software ), garantindo que a segurança seja 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 a regulamentação em matéria de cibersegurança continua a evoluir, OPSWAT o seu compromisso de alinhar a sua Estrutura Secure com os requisitos regulamentares globais, a começar pela Lei da Ciber-Resiliência da UE e pela Diretiva NIS2. Ao adaptar-se de forma proativa às normas emergentes, OPSWAT que a sua Secure se mantém abrangente, em conformidade e resiliente num panorama regulamentar cada vez mais complexo.

A manutenção de uma segurança da informação robusta é fundamental tanto para a integridade operacional como para a conformidade regulamentar. O Secure Framework OPSWAT incorpora os princípios do SGSI (Sistema de Gestão da Segurança da Informação) da norma ISO 27001, garantindo que os controlos de segurança, as estratégias de gestão de riscos e as medidas de conformidade sejam 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, Secure Framework OPSWATestá integrado no Sistema de Gestão da Qualidade (SGQ) ISO 9001. O SGQ estabelece controlos de qualidade auditados para a governação, a gestão da mudança e os processos interfuncionais, apoiando a definição, a conceção, o desenvolvimento, a produção e a manutenção do produto e das ofertas de apoio, estendendo-se para além da I&D a áreas como as vendas, o apoio ao cliente, as tecnologias da informação e os 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 OPSWAT traduz o Quadro Secure numa governança estruturada, garantindo que os requisitos de segurança sejam documentados, mantidos, avaliados e continuamente melhorados, assegurando simultaneamente que todas as partes envolvidas recebam 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 do pipeline, definindo o Ambiente Secure e exigindo a aplicação de políticas de segurança no âmbito do Processo Secure .

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

O Diretor de Produto (CPO) é responsável pela supervisão estratégica e pela implementação do Programa Secure em todas as equipas de produto, bem como de outros programas de Investigação e Desenvolvimento (I&D), tais 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.

Na qualidade de principal responsável pelo risco de todos os produtos e processos de I&D, o CPO incumbe a área de Operações de I&D de assumir a responsabilidade pelo Programa Secure e assegura que os responsáveis pelos produtos velem pela aplicação do Programa Secure e implementem o Processo Secure de forma eficaz nas equipas de produto. Nesta função, o CPO aprova as alterações ao Programa Secure , bem como os desvios em relação ao Processo Secure .

O CPO também acompanha os resultados do Programa Secure , monitorizando a maturidade em matéria de segurança, as vulnerabilidades, a conformidade e as atividades de desenvolvimento, com vista a manter uma postura de segurança sólida dos produtos.

Além disso, o CPO é responsável pela atribuição e aprovação do orçamento de segurança para a I&D, garantindo que sejam atribuídos recursos adequados ao Programa Secure .

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.

No âmbito do Programa Secure , para além das formações gerais de sensibilização para a segurança ministradas pela empresa, é obrigatória a realização de formações específicas em segurança para todos os colaboradores 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 empenhada em melhorar continuamente o seu Programa Secure através de uma medição estruturada do desempenho, avaliações de maturidade e atualizações regulares, de modo a garantir a eficácia contínua da segurança.  

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 avaliar eficazmente o nível de segurança das aplicações, OPSWAT as equipas utilizando métricas estruturadas. A maturidade de segurança dos produtos é avaliada por equipa com base no quadro SAMM, proporcionando uma medida quantificável do progresso em matéria de segurança. Além disso, os produtos são submetidos a uma avaliação de conformidade com o ASVS para garantir o cumprimento dos requisitos de verificação de segurança. A conformidade com o Processo Secure é acompanhada de perto e avaliada, e a consecução das metas dos KPI baseia-se em dados concretos, garantindo que o nível de segurança e as melhorias de segurança sejam mensuráveis e passíveis de ação. Todas as equipas de produto são obrigadas a cumprir as metas de maturidade de segurança como parte da sua avaliação de desempenho anual. 

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 da segurança, OPSWAT uma revisão anual do quadro Secure , incorporando conclusões decorrentes de análises das causas profundas de incidentes de segurança anteriores, avaliações das tendências em matéria de vulnerabilidades e aperfeiçoamentos aos 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 concretiza ainda mais o Programa Secure , definindo os controlos de segurança que as equipas devem seguir, incluindo atividades 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 é descrito em pormenor nas secções seguintes:

• Secure e avaliação de riscos
• Secure , compilação e disponibilização Secure
• Teste e verificação da segurança das aplicações
• Secure
• Secure e Manutenção Secure

O Processo Secure é um processo de alto nível; as equipas podem implementá-lo de forma alargada e personalizada, desde que a segurança do processo seja mantida, no mínimo, ao mesmo nível. Qualquer desvio em relação ao Processo Secure deve ser documentado e aprovado.

O Programa Secure inclui várias políticas que têm de ser formalmente aprovadas e aceites pelas equipas de produto, a fim de garantir o cumprimento dos seus requisitos. O cumprimento destas políticas é obrigatório a nível interno, e cada equipa é responsável por as rever, assinar e implementar no âmbito 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.

No âmbito do Processo Secure , os requisitos de segurança são acompanhados, documentados e mantidos ao longo de todo o ciclo de vida do desenvolvimento. Os fornecedores externos são obrigados a reconhecer e a cumprir a ASVS, garantindo a consistência nas expectativas de segurança e o cumprimento da Política de Conformidade de Privacidade do Produto em todos os componentes de software. 

A segurança está integrada em todas as fases do ciclo de vida do desenvolvimento. Cabe aos responsáveis pela segurança ter em conta as expectativas do Processo Secure e representá-las junto das suas equipas. 

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

A modelação de ameaças é um processo estruturado destinado a identificar ameaças e vulnerabilidades nas fases iniciais do ciclo de vida do desenvolvimento. Constitui parte integrante do Processo Secure , sendo realizada regularmente — pelo menos uma vez por ano ou sempre que sejam introduzidas novas funcionalidades ou alterações arquitetónicas. As equipas de produto realizam a modelação de ameaças definindo objetivos de segurança, identificando ativos e dependências, analisando cenários de ataque potenciais 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.

No âmbito do Processo Secure , que inclui a Implementação, a Compilação e a Implantação, o objetivo é prevenir vulnerabilidades e falhas, com base no Secure e na Avaliação de Risco. O conjunto de requisitos inclui expectativas relativas a requisitos de segurança funcionais e não funcionais baseados no ASVS, bem como a uma metodologia de desenvolvimento e teste segura, que assenta no Ambiente Secure .  

Durante a implementação, devem ser aplicadas as melhores práticas Secure , a revisão Secure e a deteção precoce de falhas de segurança. As equipas devem cumprir a Política Supply Chain (incluindo questões relacionadas com a integração de fornecedores e software de código aberto), a Política de Utilização de IA e a Política de Tratamento de Amostras de Malware. Durante a compilação e a implementação, é obrigatória Secure e implementação Secure , com utilização de um pipeline de CI/CD centralizado 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.

No âmbito das revisões de segurança exigidas pela Política de Verificação da Segurança das Aplicações, a revisão de código seguro é importante e é realizada em função da tecnologia de desenvolvimento utilizada, aplicando-se várias listas de verificação Secure baseadasna série «OWASP 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.

No âmbito do processo Secure , a utilização de um pipeline de CI/CD centralizado e orquestrado é obrigatória para garantir compilações seguras e evitar ataques à cadeia de abastecimento. Os registos de auditoria, compilação e implementação são gerados, conservados e analisados 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 acompanhamento das falhas detetadas e utilizamos ferramentas automatizadas para a verificação contínua. No âmbito do Processo Secure , são aplicadas e acompanhadas verificações de segurança em todas as fases do SDLC, de modo a cumprir os requisitos de conformidade. O objetivo destas verificações é detetar de forma eficiente possíveis falhas de segurança. As falhas de segurança detetadas são investigadas pelas equipas e resolvidas dentro dos prazos estabelecidos. Esses 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.

No âmbito do Processo Secure , o processo de lançamento impõe critérios de lançamento que garantem tanto a conformidade com o Processo Secure como a segurança global do produto, com base nas conclusões decorrentes dos Testes e Verificação de Segurança das Aplicações. O controlo de versões do produto desempenha um papel crucial na manutenção das melhorias de segurança ao longo dos lançamentos, na prevenção de regressões relacionadas com a segurança e na preservação do nível de segurança alcançado, como requisito fundamental para cada lançamento. 

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 criar, compilar ou testar o software deve incluir informações de proveniência e provir de uma fonte validada. O número de ferramentas utilizadas no pipeline de CI/CD é limitado; apenas as ferramentas necessárias são instaladas. Apenas é permitido o uso de software LTS nas etapas de compilação e criação do pipeline. No âmbito da operação dos serviços centralizados, são definidos períodos regulares de manutenção e de rotação de chaves. As ferramentas desenvolvidas internamente estão sujeitas ao Processo Secure .

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 escalamento para violações Secure : Quaisquer violações desta política são tratadas internamente, começando pela equipa de Operações de I&D e sendo escaladas até ao Diretor de Produto (CPO), se necessário.

Espera-se que os fornecedores que disponibilizam componentes ou serviços para produtos abrangidos pelas normas ISO 27001, SOC2 e NIST SSDF cumpram os requisitos abaixo descritos no Quadro de Referência Secure . O cumprimento está sujeito a auditorias de segurança periódicas, avaliações realizadas por terceiros e às obrigações de cada parte nos termos dos contratos celebrados. 

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 devem criar ambientes de desenvolvimento alinhados com as nossas práticas, tal como descrito na secção «Ambiente Secure ». Devem realizar testes de segurança aos seus componentes e bibliotecas, tal como descrito na secção «Testes e Verificação de Segurança de Aplicações». 

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

Espera-se que os prestadores de serviços utilizem ambientes sediados nos EUA que ofereçam um nível de segurança comparável ao dos serviços OPSWAT. O seu Secure deve incluir tanto um Programa Secure como um Processo Secure que reflitam as expectativas OPSWAT.