Catálogo Base de Requisitos de Segurança

Este catálogo constitui a referência canónica de requisitos de segurança aplicacional do SbD-ToE. Cada requisito é identificado por um ID canónico estável (CATEGORIA-NNN), tem aplicabilidade definida por nível de risco (L1–L3) e um critério de aceitação mínimo que permite validação objectiva e integração directa em backlogs, definições de pronto e processos de auditoria.

Âmbito: requisitos aplicacionais

Este catálogo cobre requisitos de segurança intrínsecos ao software - as propriedades que o sistema deve garantir em tempo de execução, independentemente de onde é deployed ou como a infraestrutura está definida. Incluem-se: autenticação e gestão de identidade, controlo de acesso, registo e monitorização, gestão de sessões, validação de dados, tratamento de erros, configuração segura de parâmetros da aplicação, segurança de APIs e integrações, e requisitos de processo como gestão de requisitos, distribuição de artefactos e ferramentas de desenvolvimento.

Mapeamento de catálogos por domínio técnico

O SbD-ToE organiza os requisitos de segurança em catálogos canónicos por domínio técnico, distribuídos pelos capítulos do manual. Cada catálogo tem prefixo próprio, responsável típico e artefacto de referência distinto. Este é o mapa completo:

Cap.	Prefixo(s)	Domínio	Objecto	Responsável típico
01	`CLA`	Classificação de aplicações	Classificação formal de criticidade, reclassificação, risco residual e proporcionalidade de controlos	Product Owner, Tech Lead, AppSec, GRC
02	`AUT` `ACC` `LOG` `SES` `VAL` `FIL` `ERR` `CFG` `ENC` `PRI` `API` `INT` `REQ` `DST` `IDE`	Requisitos aplicacionais	Propriedades de segurança do software em runtime	Equipa de desenvolvimento
03	`THR`	Threat modeling	Identificação de ameaças, disposição formal, derivação de requisitos e rastreabilidade	Arquitecto técnico, AppSec
04	`ARC`	Arquitectura segura	Design, estrutura e decisões do sistema	Arquitecto técnico, AppSec
05	`DEP`	Dependências, SBOM e SCA	Componentes de terceiros incorporados	Equipa de desenvolvimento, AppSec
06	`DEV`	Desenvolvimento seguro	Práticas e processos de desenvolvimento	Equipa de desenvolvimento, AppSec
07	`CIC`	CI/CD seguro	O pipeline como produto de engenharia	DevSecOps, plataforma
08	`IAC`	Infraestrutura como Código	O projecto IaC como software	Engenharia de plataforma, DevSecOps
09	`CNT`	Containers e imagens	O artefacto container e políticas de execução	DevSecOps, desenvolvimento
10	`TST`	Testes de segurança	O programa de testes de segurança	AppSec, DevSecOps
11	`DPL`	Deploy seguro	O processo de promoção a produção	DevSecOps, Release Management
12	`OPS`	Monitorização e operações	O programa de monitorização operacional	Operations, SOC, DevSecOps
13	`TRN`	Formação e onboarding	Capacitação, onboarding verificável, Security Champions e eficácia formativa	AppSec, PeopleOps, liderança técnica
14	`GOV`	Governação e contratação	Modelo de governação, excepções, contratação e maturidade organizacional	AppSec, GRC, CISO

Cada capítulo contém o seu catálogo em addon/00-catalogo-requisitos.md (ou equivalente), com aplicabilidade por nível de risco (L1–L3) e critérios de aceitação no mesmo formato deste catálogo. A distinção entre catálogos é operacionalmente relevante: responsáveis, artefactos e ciclos de revisão diferem por domínio - um requisito do tipo ARC- é avaliado em revisão de arquitectura, não num PR de código.

Sobre a curadoria: Este catálogo foi consolidado a partir de fontes reconhecidas - OWASP ASVS, NIST SSDF, IEC 62443, entre outras - e destina-se a ser adaptado por cada organização e instanciado por cada projecto. Não é imutável: deve ser mantido como documento vivo, revisto periodicamente e ajustado ao contexto técnico e de risco. Quando um projecto não tem catálogo próprio, este serve de ponto de partida directo.

Para a instanciação em projecto e a nomenclatura operacional de rastreabilidade (SEC-Lx-DOMINIO-CODIGO), ver Taxonomia e Rastreabilidade.

Convenções

Símbolo	Significado
✔	Requisito obrigatório para este nível
-	Não aplicável ou não obrigatório a este nível

Os níveis são cumulativos: L3 inclui todos os requisitos de L1 e L2; L2 inclui todos os de L1.

AUT - Autenticação e Identidade

Requisitos que garantem que apenas entidades legítimas acedem ao sistema, com controlos proporcionais à sensibilidade das operações.

ID	Nome	L1	L2	L3	Critério de aceitação
AUT-001	MFA obrigatório	-	✔	✔	Login sem segundo factor é rejeitado; evidência de bloqueio em logs. Contam como segundo factor um autenticador criptográfico (WebAuthn/FIDO2, passkey), um código TOTP ou uma aprovação push com correspondência de número; uma passkey ou chave de segurança com verificação do utilizador (PIN ou biometria local, `AUT-012`) cumpre sozinha o MFA. Em L3, a aplicação oferece autenticação resistente a phishing (WebAuthn/FIDO2) e exige-a às contas de administração; códigos por SMS ou e-mail não são aceites como segundo factor.
AUT-002	Política de passwords	✔	✔	✔	Sistema rejeita passwords que não cumpram a política; bloqueio evidenciado em teste.
AUT-003	Protecção contra brute force	✔	✔	✔	Conta bloqueada ou acesso atrasado após N tentativas falhadas; logs evidenciam o evento.
AUT-004	Revogação activa de sessões	✔	✔	✔	Logout invalida token/sessão imediatamente; reutilização resulta em erro autenticado.
AUT-005	Expiração automática de sessão	✔	✔	✔	Sessão termina após período de inactividade configurado; redirect para autenticação.
AUT-006	Proibição de credenciais em claro	✔	✔	✔	Auditoria confirma hashing com salt; ausência de credenciais em claro em armazenamento e transmissão.
AUT-007	Suporte a autenticação federada	-	✔	✔	Fluxo SAML/OIDC funcional e testado; log de autenticação via IdP externo disponível.
AUT-008	Step-up para acções sensíveis	-	✔	✔	Operações críticas requerem factor adicional; teste evidencia bloqueio sem step-up.
AUT-009	Reautenticação para alterações críticas	✔	✔	✔	Alterações de credenciais ou dados sensíveis exigem confirmação da identidade activa.
AUT-010	Alerta de acessos suspeitos	-	✔	✔	Acessos anómalos geram alerta ou notificação ao utilizador; log do evento disponível.
AUT-011	Sem credenciais por defeito	✔	✔	✔	A aplicação não é entregue nem posta em produção com contas ou credenciais por defeito; credenciais iniciais únicas por instalação e alteradas no primeiro uso; contas por defeito de componentes e plataformas desactivadas ou com a credencial alterada.
AUT-012	Autenticadores criptográficos e biometria local	✔	✔	✔	Quando a aplicação aceita passkeys, chaves de segurança ou outro autenticador WebAuthn/FIDO2: no registo e em cada autenticação, o servidor valida um desafio aleatório de uso único, a origem e o identificador da relying party, a assinatura com a chave pública registada e, quando a política o exige, a indicação de verificação do utilizador; um contador de assinaturas que regride, ou sinal equivalente, é tratado como possível clonagem e registado. A biometria (impressão digital, reconhecimento facial) serve apenas para desbloquear a credencial no dispositivo: o servidor recebe só a asserção assinada e nunca recebe, guarda nem compara dados biométricos. A chave pública guardada não é segredo; o `AUT-006` aplica-se aos segredos.
AUT-013	Gestão e recuperação dos factores de autenticação	✔	✔	✔	A recuperação de acesso usa um token aleatório, de uso único e com expiração curta, e não revela se a conta existe; cada recuperação e cada factor adicionado ou removido são notificados ao utilizador por um canal já registado. Em L2 e L3, o utilizador vê os seus autenticadores (nome, data de registo, último uso) e revoga qualquer um, com reautenticação (`AUT-009`); revogar um autenticador ou recuperar a conta termina as sessões estabelecidas com ele; perdido um factor, a recuperação exige outro autenticador registado, códigos de recuperação de uso único ou reverificação forte da identidade, nunca apenas o e-mail, e a biometria nunca é factor único de recuperação. Em L3, as recuperações de contas de administração são registadas e revistas.

ACC - Controlo de Acesso

Requisitos que asseguram que cada entidade acede apenas aos recursos e operações que lhe são explicitamente permitidos.

ID	Nome	L1	L2	L3	Critério de aceitação
ACC-001	Controlo de acesso RBAC	✔	✔	✔	Perfis e permissões mapeados; role com privilégio reduzido não acede a recursos restritos.
ACC-002	Princípio do menor privilégio	✔	✔	✔	Contas sem permissões desnecessárias; auditoria evidencia restrição efectiva.
ACC-003	Bloqueio e auditoria de acessos ilegítimos	✔	✔	✔	Tentativas de acesso não autorizado são bloqueadas e registadas com contexto suficiente.
ACC-004	Separação de perfis	✔	✔	✔	Perfis de utilizador, administrador e serviço são distintos; acções de cada perfil são rastreáveis.
ACC-005	Controlo de acesso a APIs e serviços	✔	✔	✔	Endpoints rejeitam chamadas não autenticadas ou não autorizadas; logs registam rejeições.
ACC-006	Protecção de recursos sensíveis	✔	✔	✔	Acesso não autorizado a dados críticos é impedido e registado; teste de bypasse falha.
ACC-007	Validação do modelo de acesso	-	✔	✔	Modelo de permissões revisto e documentado; ameaças de controlo de acesso mapeadas.
ACC-008	Revogação em tempo real	✔	✔	✔	Remoção de acesso reflecte-se imediatamente; teste de permissão falha após revogação.
ACC-009	Autorização baseada em atributos (ABAC)	-	-	✔	Decisão de acesso depende de atributos dinâmicos; logs evidenciam avaliação de política.
ACC-010	Revisão periódica de permissões	✔	✔	✔	Auditorias periódicas removem permissões obsoletas; registos de revisão mantidos e datados; cadência mínima (escolha do Manual): anual em L1, semestral em L2, trimestral em L3.

LOG - Registo e Monitorização

Requisitos que garantem a existência de evidência auditável das operações do sistema, suportando detecção de incidentes e resposta forense.

ID	Nome	L1	L2	L3	Critério de aceitação
LOG-001	Registo de eventos críticos	✔	✔	✔	Acessos, alterações e falhas de segurança críticas são registados; logs verificados por amostragem.
LOG-002	Atributos mínimos em logs	✔	✔	✔	Cada entrada inclui: quem, quando, o quê e onde; ausência de qualquer atributo falha auditoria.
LOG-003	Protecção de integridade e acesso aos logs	✔	✔	✔	Logs não alteráveis por utilizadores comuns; protecção por permissões ou assinatura verificável.
LOG-004	Análise periódica de logs	-	✔	✔	Processo de análise periódica documentado e evidenciado; frequência proporcional ao risco.
LOG-005	Retenção mínima dos logs	✔	✔	✔	Logs mantidos pelo período definido em política; verificação de retenção efectiva.
LOG-006	Envio para sistema centralizado	-	✔	✔	Eventos críticos enviados e registados em agregador central (SIEM ou equivalente).
LOG-007	Classificação e detecção de anomalias	-	✔	✔	Política de severidade definida; anomalias disparam alertas configurados e testados.
LOG-008	Alarme em falhas do mecanismo de logging	-	✔	✔	Falhas do sistema de logging geram alerta; ausência de logs é detectada e notificada.
LOG-009	Logs suportam resposta a incidentes	-	✔	✔	Logs com detalhe suficiente para reconstrução de incidente; testado em exercício ou simulação.
LOG-010	Logging de eventos críticos de negócio	-	-	✔	Eventos de impacto no negócio (transacções, autorizações críticas) registados e rastreáveis.

SES - Sessões e Estado

Requisitos que controlam o ciclo de vida de sessões e tokens, prevenindo reutilização, fixação e persistência indevida.

ID	Nome	L1	L2	L3	Critério de aceitação
SES-001	Expiração automática por inactividade	✔	✔	✔	Sessão termina após período configurado de inactividade; redirect para autenticação.
SES-002	Logout manual e após alteração de credenciais	✔	✔	✔	Logout termina todas as sessões activas; alteração de password invalida tokens anteriores.
SES-003	Identificadores de sessão imprevisíveis	✔	✔	✔	Tokens/sessões com entropia adequada; análise de previsibilidade não revela padrão.
SES-004	Transmissão segura dos tokens	✔	✔	✔	Tokens transmitidos apenas por canais TLS; cookies com flags Secure e HttpOnly.
SES-005	Ligação da sessão ao contexto do cliente	-	✔	✔	Mudança de IP ou user-agent termina sessão ou exige revalidação; teste evidencia comportamento.
SES-006	Revogação explícita da sessão	✔	✔	✔	Sessão pode ser terminada a pedido do utilizador ou do sistema; token fica inválido imediatamente.
SES-007	Prevenção de sessões long-lived	-	✔	✔	TTL máximo configurado e aplicado; sessões com duração excessiva não são possíveis.
SES-008	Scope, TTL e revogação de tokens JWT	-	✔	✔	JWTs incluem claims de âmbito e expiração; mecanismo de revogação implementado e testado.

VAL - Validação de Dados

Requisitos que garantem que apenas dados bem formados e esperados são processados pelo sistema, prevenindo injecções e comportamentos não determinísticos.

ID	Nome	L1	L2	L3	Critério de aceitação
VAL-001	Validação geral de entradas externas	✔	✔	✔	Inputs inválidos são rejeitados com código de erro adequado; logs evidenciam bloqueio.
VAL-002	Uso de whitelists em vez de blacklists	✔	✔	✔	Apenas valores explicitamente aceites são permitidos; valores não previstos são rejeitados.
VAL-003	Validadores de esquema (JSON/XML schema)	-	✔	✔	Payloads malformados são rejeitados automaticamente; logs de parsing disponíveis.
VAL-004	Sanitização contra injecções	✔	✔	✔	Inputs potencialmente perigosos são neutralizados; ataques de injecção resultam em falha controlada.
VAL-005	Validação antes do uso interno	✔	✔	✔	Dados são validados antes de uso em lógica de negócio ou persistência; não há caminhos não validados.
VAL-006	Mensagens de erro seguras na validação	✔	✔	✔	Erros de validação não expõem lógica interna nem dados sensíveis ao cliente.
VAL-007	Testes automáticos contra entradas maliciosas	-	✔	✔	Testes automatizados cobrem XSS, SQLi e outras injecções relevantes; resultados registados.
VAL-008	Codificação/escaping de output em renderização (anti-XSS)	✔	✔	✔	Output é codificado de forma contextual ao destino de renderização (HTML/atributo/JavaScript, queries via prepared statements, comandos shell, logs anti-injection); ausência de concatenação directa em superfícies sensíveis.

FIL - Tratamento de Ficheiros

Um ficheiro é input — a forma de o validar é que difere: além do valor, contam o tipo real do conteúdo, o custo de o processar e o sítio onde fica armazenado e de onde é servido. Os requisitos VAL-* cobrem a validação de dados; os FIL-* cobrem o que é específico de ficheiros — aceitação, conteúdo, arquivos comprimidos, quota, armazenamento e serving — sem duplicar a validação genérica.

ID	Nome	L1	L2	L3	Critério de aceitação
FIL-001	Limite de tamanho processável por upload	✔	✔	✔	Ficheiros acima do limite definido por funcionalidade são rejeitados antes de qualquer processamento; o limite está documentado.
FIL-002	Validação de tipo por conteúdo, não só por extensão	✔	✔	✔	A extensão confere com o tipo esperado e o conteúdo corresponde ao tipo (verificação de magic bytes, re-writing de imagens ou biblioteca de validação de conteúdo); ficheiros não conformes são rejeitados.
FIL-003	Tratamento seguro de arquivos comprimidos	-	✔	✔	Antes de descomprimir: tamanho máximo descomprimido e número máximo de ficheiros verificados; symlinks rejeitados salvo allowlist explícita; a descompressão ignora caminhos fornecidos pelo utilizador (zip slip).
FIL-004	Quota de armazenamento por utilizador	-	✔	✔	Quota de espaço e número máximo de ficheiros por utilizador activos; tentativa de exceder é rejeitada com registo.
FIL-005	Armazenamento fora da árvore servida, com nomes gerados	✔	✔	✔	Ficheiros de origem não confiável não são executáveis como código do servidor quando acedidos por HTTP; caminhos de operações de ficheiro usam nomes gerados internamente, ou validação estrita quando o nome do utilizador é inevitável.
FIL-006	Serving de ficheiros em contexto inerte	-	✔	✔	Nomes de ficheiro servidos são validados ou sanitizados e declarados em `Content-Disposition` (RFC 6266); conteúdo de utilizador é servido de forma não interpretável como HTML ou script no domínio da aplicação.
FIL-007	Rastreio anti-malware de ficheiros de origem não confiável	-	✔	✔	Ficheiros recebidos de fontes não confiáveis passam por rastreio anti-malware antes de serem disponibilizados; detecção bloqueia a disponibilização e gera registo.
FIL-008	Limite de dimensão de imagens (pixel flood)	-	✔	✔	Imagens com dimensão em píxeis acima do máximo definido são rejeitadas onde a aplicação processa imagens.

Proporcionalidade de FIL-002 em L1 (da fonte de derivação, ASVS 5.0 V5.2.2): "For L1, this can focus just on files which are used to make specific business or security decisions. For L2 and up, this must apply to all files being accepted." — em L1 a validação de conteúdo pode limitar-se aos ficheiros que sustentam decisões de negócio ou segurança; em L2+ aplica-se a todos os ficheiros aceites.

Fontes. Derivação por linha: FIL-001 — ASVS 5.0 V5.2.1, ASVS 5.0 V5.1.1; FIL-002 — ASVS 5.0 V5.2.2, ASVS 5.0 V5.1.1, CWE-434; FIL-003 — ASVS 5.0 V5.2.3, ASVS 5.0 V5.2.5, ASVS 5.0 V5.3.3; FIL-004 — ASVS 5.0 V5.2.4; FIL-005 — ASVS 5.0 V5.3.1, ASVS 5.0 V5.3.2, CWE-434; FIL-006 — ASVS 5.0 V5.4.1, ASVS 5.0 V5.4.2 (a cláusula de conteúdo não interpretável no domínio da aplicação é prescrição editorial do SbD-ToE); FIL-007 — ASVS 5.0 V5.4.3 (a cláusula "e gera registo" é prescrição editorial); FIL-008 — ASVS 5.0 V5.2.6. As fontes ancoram a derivação; a prescrição, a redação e o escalamento L1–L3 são editoriais do SbD-ToE.

ERR - Gestão de Erros

Requisitos que asseguram que erros e excepções são tratados de forma controlada, sem exposição de informação sensível ou lógica interna.

ID	Nome	L1	L2	L3	Critério de aceitação
ERR-001	Erros não expõem dados sensíveis	✔	✔	✔	Mensagens ao cliente são abstractas; logs internos detalhados nunca expostos externamente.
ERR-002	Mensagens genéricas no cliente	✔	✔	✔	Cliente recebe sempre mensagem genérica; stack traces e detalhes internos não transmitidos.
ERR-003	Não revelar existência de recursos	✔	✔	✔	Respostas de erro são idênticas para recursos existentes e inexistentes (sem enumeração).
ERR-004	Mensagens localizadas e seguras	✔	✔	✔	Mensagens traduzidas sem conteúdo executável ou referências a lógica interna.
ERR-005	Gestão padronizada e centralizada	-	✔	✔	Framework de erros centraliza tratamento e logging; ausência de tratamento ad-hoc disperso.
ERR-006	Testes automáticos para erros excessivos	-	✔	✔	Testes garantem que erros são tratados e não há fuga de informação; cobertura de casos limite.
ERR-007	Logs de erro com contexto pseudonimizado	-	✔	✔	Logs incluem IDs contextuais; dados pessoais ou credenciais nunca registados em logs de erro.

CFG - Configuração Segura

Requisitos que garantem que o sistema é configurado e operado de forma que minimize a superfície de ataque e previna exposição acidental.

ID	Nome	L1	L2	L3	Critério de aceitação
CFG-001	Debug e flags desactivados em produção	✔	✔	✔	Parâmetros de debug, trace e dev_mode desligados em produção; verificação automática no pipeline.
CFG-002	Separação de ambientes com validação automática	✔	✔	✔	Deploys e testes apenas em ambientes segregados; logs evidenciam segregação efectiva.
CFG-003	Ausência de parâmetros hardcoded	✔	✔	✔	Código fonte não contém segredos nem parâmetros sensíveis em claro; scan automatizado confirma.
CFG-004	Configuração externa com permissões controladas	✔	✔	✔	Configuração é externa ao código; permissões de acesso ao repositório de configuração são restritivas.
CFG-005	Validação de configuração no arranque	-	✔	✔	Sistema falha arranque quando parâmetros obrigatórios estão em falta ou incorrectos; erro explícito.
CFG-006	Uso de cofres e gestão segura de segredos	-	✔	✔	Segredos existem apenas em cofres seguros; auditoria evidencia ausência de segredos no repositório.
CFG-007	Monitorização de drift de configuração	-	-	✔	Alterações inesperadas em configuração crítica disparam alertas; baseline documentada.

ENC - Dados Sensíveis e Criptografia

Requisitos que garantem a protecção de dados sensíveis em trânsito e em repouso, o uso de primitivas criptográficas robustas e a prevenção de exposição acidental de segredos e dados pessoais.

ID	Nome	L1	L2	L3	Critério de aceitação
ENC-001	Encriptação de todas as comunicações em trânsito	✔	✔	✔	Toda a comunicação entre cliente e servidor e entre serviços internos usa TLS com versão mínima definida; versões inseguras (TLS 1.0, 1.1, SSLv3) desactivadas e verificáveis por configuração.
ENC-002	Encriptação de dados sensíveis em repouso	-	✔	✔	Dados classificados como sensíveis (PII, credenciais, dados financeiros) encriptados em armazenamento persistente; chaves de encriptação geridas separadamente dos dados; evidência de aplicação a todos os datastores relevantes.
ENC-003	Algoritmos e configurações criptográficas robustas	-	✔	✔	Apenas algoritmos aprovados e tamanhos de chave adequados em uso (ex: AES-256, RSA ≥ 2048, curvas elípticas aprovadas); algoritmos fracos ou deprecados (MD5, SHA-1 para integridade, DES) ausentes; lista de primitivas aprovadas documentada. Inventário das primitivas, bibliotecas e protocolos criptográficos por componente, mantido com o SBOM; a lista de primitivas é revista pelo menos anualmente e sempre que um aviso de criptoanálise a afecte (incluindo a transição pós-quântica). Em L3, os algoritmos podem ser trocados por configuração, sem alterar o código.
ENC-004	Hashing adaptativo de passwords	✔	✔	✔	Passwords armazenadas com algoritmo adaptativo resistente a força bruta (bcrypt, Argon2, PBKDF2); factor de custo configurado e revisto periodicamente; ausência de hashing estático ou reversível confirmada.
ENC-005	Mascaramento de dados sensíveis em logs, outputs e respostas API	✔	✔	✔	Passwords, tokens, números de cartão, dados pessoais sensíveis não aparecem em claro em logs, respostas de erro ou outputs de debugging; cobertura verificada por análise de logs e teste.
ENC-006	Detecção e prevenção de segredos expostos em repositórios	✔	✔	✔	Ferramenta de detecção de segredos activa no pipeline (ex: truffleHog, gitleaks, detect-secrets); commits com segredos detectados bloqueados ou alertados; sem segredos em claro no histórico do repositório.
ENC-007	Ciclo de vida de chaves, segredos e certificados	-	✔	✔	Política de rotação definida por tipo de segredo; rotação executada nos prazos definidos; evidência de rotação auditável; ausência de chaves sem data de expiração para material crítico. Cada chave criptográfica tem ciclo de vida definido (geração, distribuição, armazenamento, cópia de segurança, arquivo, recuperação, revogação e destruição), com regras de utilização por tipo de chave; as chaves retiradas guardam-se só para decifrar dados existentes. Os certificados constam de um inventário com dono, validade e local de guarda da chave, com alerta antes da expiração e renovação automatizada quando possível (Política 18 §6.4).
ENC-008	Prevenção de caching de dados sensíveis no cliente	-	✔	✔	Respostas com dados sensíveis incluem cabeçalhos que inibem caching (Cache-Control: no-store, etc.); configuração verificável por análise de headers em ambiente de teste.
ENC-009	Integridade verificável de dados críticos	-	-	✔	Dados críticos com mecanismo de verificação de integridade (MACs, assinaturas, checksums); adulterações detectadas e registadas; cobertura aplicada a dados com impacto de negócio ou regulatório.

PRI - Dados Pessoais (engenharia)

Requisitos de engenharia sobre dados pessoais: o que se recolhe, por quanto tempo fica, e o que o sistema é capaz de fazer com esses dados. O lado legal — bases legais, direitos formais, obrigações regulatórias — não vive neste catálogo: é matéria do cross-check normativo e do overlay regulatório.

Uma aplicação com dados pessoais pode ser L1 (dados pessoais valem D=2, e E1+D2+I1 = 4). Por isso PRI-001, PRI-002, PRI-003, PRI-006 e PRI-007 aplicam-se desde L1: o dano ao titular não depende do nível. O inventário (PRI-004) e o conceito de PII em registos (PRI-005) ficam em L2/L3; quando o RGPD se aplica, o overlay regulatório sobe-os a todos os níveis.

ID	Nome	L1	L2	L3	Critério de aceitação
PRI-001	Minimização dos dados pessoais recolhidos	✔	✔	✔	Cada campo de dados pessoais recolhido está associado a uma finalidade registada; campos sem finalidade são removidos do fluxo de recolha.
PRI-002	Retenção de dados pessoais com prazo e apagamento efectivo	✔	✔	✔	Conjuntos de dados pessoais têm prazo de retenção definido; o apagamento no fim do prazo é executado, chega às réplicas, caches e sistemas a jusante, e é verificável por amostragem ou evidência automática; nas cópias de segurança, os dados expiram com o ciclo de retenção das cópias, num prazo declarado. A anonimização irreversível é alternativa aceite ao apagamento. Quando a organização trata dados por conta de um cliente, no fim do serviço os dados e as respectivas cópias são apagados ou devolvidos, conforme o contrato, com evidência.
PRI-003	Capacidade técnica de acesso, rectificação, apagamento e exportação a pedido	✔	✔	✔	Existe mecanismo testado, sem intervenção manual em base de dados, para, sobre os dados pessoais de um titular identificado: exportar uma cópia em formato estruturado, de uso corrente e de leitura automática; rectificar e completar; apagar, incluindo réplicas, caches e sistemas a jusante. As rectificações e os apagamentos propagam-se aos destinatários conhecidos (em L2/L3, os registados em `PRI-004`). Um pedido recebido fora do canal autenticado só é executado depois de verificada a identidade de quem pede. Em L1, basta um procedimento documentado com função administrativa ou script testado; em L2/L3, é funcionalidade da aplicação ou do backoffice e cada execução fica registada.
PRI-004	Registo de finalidade e destinatários por conjunto de dados pessoais	-	✔	✔	Inventário associa cada conjunto de dados pessoais à finalidade, ao sistema que o trata e aos destinatários, internos e externos, a quem é comunicado; alterações de finalidade ou de destinatários são registadas.
PRI-005	Conceito documentado e aplicado de PII em registos	-	✔	✔	Existe um conceito documentado de tratamento de PII em registos (o que se regista, mascarado como, por quanto tempo) e a sua aplicação é verificada. Nos registos e cópias imutáveis (WORM), os dados pessoais entram só como identificador pseudónimo; qualquer conteúdo identificador vai cifrado com uma chave por titular, e o apagamento cumpre-se destruindo essa chave (Política 29 §8).
PRI-006	Gestão técnica do consentimento e das preferências de oposição	✔	✔	✔	Quando a aplicação trata dados com base em consentimento, ou permite recusar um tratamento (p. ex. comunicações de marketing, definição de perfis): cada consentimento fica registado de forma auditável (titular, momento, finalidade, versão do texto apresentado); a retirada ou a oposição está disponível pelo mesmo canal e não exige mais esforço do que o consentimento; produz efeito nos tratamentos dependentes e persiste, sem ser reposta por reimportações ou sincronizações.
PRI-007	Privacidade por defeito nas definições voltadas ao utilizador	✔	✔	✔	As definições de partilha, visibilidade e tratamento opcional começam na opção mais protectora: os tratamentos opcionais exigem acção do utilizador (opt-in) e os perfis e conteúdos pessoais não ficam visíveis a um número indeterminado de pessoas sem intervenção do utilizador; a configuração por defeito é verificada em teste.

Os vizinhos existentes mantêm o seu objecto: ENC-005 proíbe dados sensíveis em claro em logs, outputs e respostas API; ERR-007 exige contexto pseudonimizado nos logs de erro (L2+); LOG-005 fixa a retenção mínima dos logs. PRI-002 fixa a retenção máxima dos dados pessoais de negócio, e PRI-005 acrescenta o que nenhum deles prescreve: o conceito documentado e verificado — não repete a proibição, exige o conceito.

Fontes. PRI-001…004, PRI-006 e PRI-007 — prescrição do SbD-ToE (ameaça de referência: CWE-359); PRI-005 — actividade DSOMM "PII logging concept" ("A concept how to log PII is documented and applied") e CWE-359. As fontes ancoram a derivação; a prescrição é editorial do SbD-ToE.

API - Segurança de APIs

Requisitos específicos para superfícies de API, que constituem o vector de exposição mais frequente em aplicações modernas.

ID	Nome	L1	L2	L3	Critério de aceitação
API-001	Autenticação e autorização de chamadas API	✔	✔	✔	Endpoints rejeitam chamadas sem autenticação/autorização válida; chamadas anónimas falham.
API-002	Endpoints desnecessários removidos ou ocultos	✔	✔	✔	Endpoints de debug ou legacy não expostos em produção; apenas em ambientes de teste controlados.
API-003	Validação de input em APIs	✔	✔	✔	Inputs malformados são rejeitados; logs registam tentativa com contexto mínimo.
API-004	Rate limiting e detecção de abusos	-	✔	✔	Limite configurado e activo; chamadas excessivas resultam em 429 ou bloqueio temporário.
API-005	Protecção por TLS e certificados actualizados	✔	✔	✔	Canal TLS obrigatório; certificados válidos, com alerta antes da expiração; cabeçalhos de segurança (HSTS, etc.) activos.
API-006	Verificação de SDKs e wrappers utilizados	✔	✔	✔	Dependências e versões documentadas em SBOM; auditoria de licenças e vulnerabilidades conhecidas.
API-007	Logging e auditoria de chamadas externas	-	✔	✔	Chamadas externas registadas com dados essenciais (origem, destino, resultado, timestamp).

INT - Mensagens e Integrações

Requisitos que asseguram a segurança nas comunicações entre sistemas, prevenindo intercepção, falsificação e injecção em canais de integração.

ID	Nome	L1	L2	L3	Critério de aceitação
INT-001	Validação de mensagens entre sistemas	✔	✔	✔	Mensagens malformadas são rejeitadas ou tratadas de forma controlada; sem processamento cego.
INT-002	Autenticação mútua ou tokens seguros	✔	✔	✔	Integrações só aceites de fontes autenticadas; tokens verificados e com TTL definido.
INT-003	Transmissão cifrada com TLS	✔	✔	✔	Todo o tráfego entre sistemas cifrado com TLS; versões inseguras desactivadas.
INT-004	Proibição de protocolos inseguros	✔	✔	✔	Protocolos sem cifra (HTTP, FTP, Telnet) rejeitados ou redirecionados para equivalente seguro.
INT-005	Assinatura e integridade de mensagens	-	✔	✔	Mensagens sensíveis assinadas e verificadas; logs evidenciam verificação de integridade.
INT-006	Validação cruzada de origem e destino	-	✔	✔	Apenas origens e destinos autorizados aceites; logs de rejeição mantidos.
INT-007	Monitorização e detecção de padrões anómalos	-	-	✔	Comportamento anómalo nos canais de integração dispara alertas; logs analisados periodicamente.
INT-008	Revisão de segurança e contrato em integrações	-	-	✔	Integrações documentadas com cláusulas de segurança; checklist de revisão executada.
INT-009	Consumidores idempotentes	-	✔	✔	Reprocessar a mesma mensagem não produz efeitos duplicados; a idempotência é testada.
INT-010	Fila de mensagens mortas com tratamento e alarme	-	✔	✔	Mensagens não processáveis vão para DLQ; a DLQ tem tratamento definido e alarme activo — nunca cresce em silêncio.
INT-011	Protecção contra replay de mensagens	-	✔	✔	Mensagens têm identificador único e janela de validade; a reinjeção fora da janela ou duplicada é rejeitada com registo.
INT-012	Ordem de processamento onde semanticamente exigida	-	-	✔	Onde a semântica do negócio exige ordem, o processamento garante-a (chave de partição, sequenciação) e a violação é detectável.

Fontes (INT-009…012). prescrição do SbD-ToE — ciclo de vida de mensagens (idempotência, DLQ, replay, ordem); sem fonte externa que a ancore. INT-011 trata replay de mensagens, objecto distinto do replay de tokens (SES-008).

REQ - Definição de Requisitos

Requisitos que asseguram a incorporação sistemática da segurança no processo de definição e gestão de requisitos do ciclo de vida.

ID	Nome	L1	L2	L3	Critério de aceitação
REQ-001	Inclusão de requisitos de segurança	✔	✔	✔	Requisitos de segurança explícitos em backlog/documentação; marcados e rastreáveis.
REQ-002	Revisão formal de segurança dos requisitos	✔	✔	✔	Processo de revisão documentado e evidenciado; responsável identificado.
REQ-003	Alinhamento com classificação de risco	✔	✔	✔	Mapeamento entre requisitos e nível de criticidade disponível e actualizado.
REQ-004	Versionamento e gestão de requisitos	✔	✔	✔	Histórico de alterações disponível; controlo de versões aplicado ao catálogo do projecto.
REQ-005	Nova análise de ameaça após alteração de requisito	-	✔	✔	Alterações relevantes disparam revisão de threat modeling; registo da decisão disponível.
REQ-006	Rastreabilidade requisito → ameaça → teste	-	✔	✔	Matriz ou ferramenta demonstra ligação entre requisitos, ameaças identificadas e testes.
REQ-007	Revisão iterativa com equipas	-	✔	✔	Alterações de requisitos discutidas, revistas e registadas em ciclos definidos.

DST - Distribuição de Artefactos

Requisitos que garantem a integridade e rastreabilidade dos artefactos ao longo do processo de build, publicação e distribuição.

ID	Nome	L1	L2	L3	Critério de aceitação
DST-001	Repositórios autenticados e auditáveis	✔	✔	✔	Autenticação obrigatória e logs activos para acesso a repositórios de artefactos.
DST-002	Aprovação para publicação pública	-	✔	✔	Publicação em registry público requer aprovação e documentação formal do processo.
DST-003	Assinatura digital ou checksum	-	✔	✔	Artefactos assinados ou validados por hash antes de publicação; verificação automatizada; as actualizações distribuídas a utilizadores ou clientes levam assinatura ou hash publicados, que o produto ou quem instala verifica antes da instalação.
DST-004	Inclusão de SBOM nos artefactos	-	✔	✔	SBOM gerado e anexado a cada release; rastreabilidade de dependências disponível.
DST-005	Acesso segregado por role e ambiente	-	✔	✔	Apenas utilizadores e automações autorizados acedem a artefactos de produção.
DST-006	Deploy apenas via pipeline validado	-	✔	✔	Artefactos só deployados por pipeline controlado e auditado; sem deploy manual em produção.
DST-007	Revogação e limpeza de artefactos comprometidos	✔	✔	✔	Versões comprometidas são removidas prontamente; utilizadores e dependentes notificados.

IDE - Ferramentas de Desenvolvimento

Requisitos que controlam o ambiente de desenvolvimento como superfície de risco, prevenindo introdução de vulnerabilidades por ferramentas ou extensões não controladas.

ID	Nome	L1	L2	L3	Critério de aceitação
IDE-001	Ferramentas e IDEs autorizadas	✔	✔	✔	Apenas ferramentas aprovadas são utilizadas; lista mantida e actualizada pela organização.
IDE-002	Actualização e gestão de vulnerabilidades	✔	✔	✔	IDEs e ferramentas mantidas actualizadas; histórico de actualizações disponível.
IDE-003	Auditoria de código gerado por ferramentas	-	✔	✔	Código gerado por ferramentas ou assistentes é revisto antes de integração em produção.
IDE-004	Extensões e plugins de fontes confiáveis	✔	✔	✔	Apenas extensões de fontes reconhecidas e verificadas são instaladas; logs de instalação.
IDE-005	Controlo de permissões de extensões	-	✔	✔	Permissões de extensões revistas; apenas as necessárias concedidas; execução sandboxed.
IDE-006	Limitação de ambientes locais sem controlo	-	✔	✔	Utilização de ambientes locais controlada; logs de rede ou proxy disponíveis quando aplicável.

Para validação detalhada por requisito, métodos de teste e evidências esperadas, ver Validação de Requisitos. Para o modelo de rastreabilidade e instanciação em projecto, ver Taxonomia e Rastreabilidade. Para a matriz de aplicabilidade por domínio e nível de risco, ver Matriz de Controlos por Risco.

Âmbito: requisitos aplicacionais​

Mapeamento de catálogos por domínio técnico​

Convenções​

Índice​

AUT - Autenticação e Identidade​

ACC - Controlo de Acesso​

LOG - Registo e Monitorização​

SES - Sessões e Estado​

VAL - Validação de Dados​

FIL - Tratamento de Ficheiros​

ERR - Gestão de Erros​

CFG - Configuração Segura​

ENC - Dados Sensíveis e Criptografia​

PRI - Dados Pessoais (engenharia)​

API - Segurança de APIs​

INT - Mensagens e Integrações​

REQ - Definição de Requisitos​

DST - Distribuição de Artefactos​

IDE - Ferramentas de Desenvolvimento​