# Gestão de vulnerabilidades para PME

> Gestão de vulnerabilidades numa PME: fontes de alertas, avaliação por risco, decisão, execução e comprovativo, com o exemplo do PHP2Shell.

Fonte: https://phpsos.de/pt/blog/schwachstellenmanagement-mittelstand/  
Atualizado em: 25/10/2026  
Prestador: PHP SOS, Assistência de emergência PHP e segurança de servidores. Ajuda imediata por WhatsApp: https://wa.me/491736494914?text=Ol%C3%A1%2C%20PHP%20SOS%2C%20precisamos%20de%20ajuda%20com%20o%20nosso%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Site%3A%20%E2%80%A6

**Em resumo:** a gestão de vulnerabilidades numa PME é um ciclo enxuto e recorrente: conhecer os sistemas, acompanhar os alertas de forma direcionada, avaliar segundo o risco, decidir, executar e comprovar. O que conta não são ferramentas caras, mas responsabilidades claras e uma priorização que tenha em conta a acessibilidade, os dados e a situação de ataque. O PHP2Shell é um bom exemplo para praticar, porque todos os passos nele aparecem.

## Centenas de alertas, pouco pessoal

Todas as semanas são publicadas novas falhas de segurança, em sistemas operativos, linguagens de programação, aplicações e plugins. Um grande grupo empresarial tem uma equipa para isso. Uma PME tem muitas vezes um responsável de TI, um ou dois administradores e vários prestadores de serviços externos. Ninguém consegue ler todos os alertas, e ninguém precisa de o fazer.

O que é preciso é um filtro: que alertas dizem respeito aos nossos sistemas, quais deles são urgentes e quem trata do assunto? Sem este filtro, acontece uma de duas coisas. Ou se ignora tudo até algo acontecer, ou cada alerta provoca agitação e o realmente crítico perde-se no ruído.

## O ciclo da gestão de vulnerabilidades

Um procedimento sustentável para PME pode descrever-se em seis passos:

1. **Registar o que está em funcionamento.** Sem inventário, não há comparação possível. Que sites, servidores, versões do PHP e aplicações opera, e onde? Como o conseguir, mostra-o [Saber o que está a correr: inventário de todos os sites e servidores](https://phpsos.de/pt/blog/inventar-websites-server/).
2. **Acompanhar os alertas.** Subscreva poucas fontes fiáveis: os avisos do BSI (Gabinete Federal Alemão para a Segurança da Informação), os alertas dos fabricantes do seu software, as páginas de segurança da sua distribuição Linux e, no caso do PHP, a página inicial do php.net.
3. **Avaliar.** O alerta diz-nos respeito? Se sim, com que urgência? Mais sobre isto adiante.
4. **Decidir.** Corrigir, proteger temporariamente, isolar o sistema ou assumir o risco conscientemente. Quem pode decidir o quê?
5. **Executar.** Instalar a atualização, aplicar uma medida provisória, contratar um prestador de serviços.
6. **Comprovar e acompanhar.** A vulnerabilidade está mesmo fechada? Quando é que uma solução provisória será substituída?

Depois, o ciclo recomeça. Entram sistemas novos, saem sistemas antigos e surgem novos alertas.

No passo 2, ajuda uma regra simples: é melhor ler com regularidade poucas fontes do que muitas de vez em quando. Para um ambiente web típico de uma PME, bastam em regra os avisos do CERT-Bund (a equipa de resposta a incidentes do governo alemão) no BSI, os alertas de segurança da distribuição Linux em uso, as páginas dos fabricantes do CMS e da loja e a página inicial do php.net. Defina quem lê estas fontes e crie para isso uma caixa de correio ou um canal partilhado que não dependa de uma única pessoa.

Vale também a pena um olhar de fora. Uma análise regular de vulnerabilidades aos sistemas acessíveis ao público mostra se há software desatualizado ou serviços desnecessariamente abertos à vista. Não substitui nem o inventário nem as atualizações, mas revela sistemas que não constam de nenhuma lista.

## Avaliar: o que vem primeiro

A pontuação CVSS, uma classificação normalizada da gravidade, é um bom ponto de partida. Para a ordem de trabalho dentro da casa, porém, não basta. Há três perguntas adicionais que decidem:

| Pergunta | Aumenta a urgência | Reduz a urgência |
|---|---|---|
| O sistema está acessível a partir da Internet? | site público, loja, portal | apenas interno, atrás de VPN |
| É preciso iniciar sessão para explorar a vulnerabilidade? | não, sem autenticação | sim, só para administradores |
| Que dados trata o sistema? | dados de clientes, pagamentos, acessos | conteúdos públicos sem contas |
| Há relatos de ataques? | tentativas de ataque comunicadas | nenhuma tentativa conhecida |
| Existe uma medida provisória? | não | sim, com eficácia comprovada |

O PHP2Shell mostra como tudo se conjuga. Ambas as vulnerabilidades têm um valor CVSS v4.0 de 9,2, permitem a execução de código sem autenticação e afetam servidores web acessíveis ao público. A Cloudflare e a Patchstack reportaram, segundo os media, tentativas de ataque; o BSI classificou a situação com o nível de alerta 3. As medidas provisórias do php.net não oferecem, expressamente, proteção completa. Todas as perguntas apontam na mesma direção: agir de imediato. O que o BSI recomendou em concreto está em [O que o BSI recomenda sobre o PHP2Shell](https://phpsos.de/pt/compliance/bsi-empfehlungen/).

## Decidir e documentar

Nem todas as vulnerabilidades se podem fechar de imediato. Um sistema antigo corre no PHP 8.1, para o qual já não existem atualizações oficiais (veja [PHP 8.1 e anteriores: o que se aplica agora](https://phpsos.de/pt/php2shell/php-8-1-und-aelter/)); uma aplicação especializada ainda não suporta a atualização. Nesse caso é preciso uma decisão, e essa decisão não pertence apenas à área técnica.

Uma boa nota de decisão contém o sistema afetado, a vulnerabilidade, a avaliação, a opção escolhida, as medidas provisórias, a pessoa responsável e uma data para nova avaliação. Quando um risco é assumido conscientemente, decide a direção, e não o administrador sozinho. O OWASP Cheat Sheet sobre o tratamento de dependências vulneráveis recomenda igualmente que a aceitação do risco fique expressamente ancorada ao nível da direção.

> **Dica:**
> Mantenha uma única lista de vulnerabilidades em aberto, com estado, responsável e prazo. Uma tabela chega. O importante é que seja revista com regularidade, por exemplo na reunião mensal com a gerência.

## O que a NIS2 e os prestadores de serviços têm a ver com isto

Para as empresas abrangidas pela NIS2, o tratamento de vulnerabilidades faz parte das obrigações de gestão de risco. Os pormenores são descritos em [NIS2 e segurança de servidores web](https://phpsos.de/pt/compliance/nis2/). Mas, mesmo sem obrigação legal, um procedimento documentado é uma vantagem, por exemplo perante clientes, seguradoras e a própria gerência.

Muitos passos podem ser externalizados, como o acompanhamento de alertas ou a instalação de atualizações. A decisão sobre riscos e a visão de conjunto devem, no entanto, permanecer dentro da casa. Quem entrega o ciclo por inteiro a um prestador de serviços acaba por não saber, numa emergência, que sistemas tem sequer. Como organizar a execução como rotina, descreve-o [Gestão de patches como processo e não como combate a incêndios](https://phpsos.de/pt/blog/patch-management-prozess/).

## Como ajuda concretamente a PHP SOS?

- Elaboramos consigo o inventário dos seus sites e servidores como base para qualquer comparação.
- Acompanhamos os alertas relevantes para os seus sistemas e entregamos uma avaliação em linguagem clara, com recomendação.
- Preparamos notas de decisão para os casos em que uma atualização não é possível de imediato.
- Através da [monitorização de segurança](https://phpsos.de/pt/leistungen/security-monitoring/), verificamos continuamente se os sistemas se tornam suspeitos enquanto uma vulnerabilidade continua aberta.

**Conclusão:** a gestão de vulnerabilidades numa PME não tem de ser grande, mas tem de ser vinculativa. Quem conhece os seus sistemas, lê poucas fontes boas e regista as decisões reage com rapidez e acerto ao próximo alerta crítico.


## Perguntas frequentes

**O que é a gestão de vulnerabilidades?**  
Um procedimento recorrente com o qual uma empresa toma conhecimento das falhas de segurança nos seus sistemas, as avalia, as corrige ou as aceita conscientemente e regista o resultado. Não se trata de uma ferramenta, mas de responsabilidades e decisões.

**A pontuação CVSS basta para definir prioridades?**  
É um bom ponto de partida, mas não chega. É decisivo saber também se o sistema afetado está acessível a partir da Internet, que dados trata e se já foram observados ataques. Uma vulnerabilidade com pontuação elevada num sistema de teste interno pode esperar; no caso da loja online, não.

**Uma pequena empresa precisa de uma ferramenta própria para isto?**  
No início, não. Basta uma lista atualizada dos sistemas, avisos de segurança subscritos e uma tabela com os pontos em aberto. Os analisadores de vulnerabilidades compensam quando o número de sistemas cresce ou quando é preciso comprovar verificações com regularidade.

**É permitido não corrigir uma vulnerabilidade de propósito?**  
Sim, desde que o risco seja avaliado, a decisão seja tomada pela direção responsável e fique registada por escrito, de preferência com medidas provisórias e uma data para nova avaliação.

## Fontes

- [BSI](https://www.bsi.bund.de/)
- [php.net: avisos de segurança](https://www.php.net/)
- [Debian Security Tracker](https://security-tracker.debian.org/)
- [OWASP: Vulnerable Dependency Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Vulnerable_Dependency_Management_Cheat_Sheet.html)