Site público estático
O site público é servido como conteúdo estático. Não tem login, área de cliente, formulário de contacto, newsletter ou endpoint de recolha comercial.
security posture
Segurança e privacidade, públicas por defeito.
Esta página descreve a postura do site público ShiftLeft.pt, como reportar vulnerabilidades, e que fronteiras assumimos para trabalho enterprise. É uma página operacional, não uma promessa de conformidade.
Minimização de dados
Não usamos analytics de marketing, tracking cookies, píxeis de terceiros ou captura de leads. O alojamento pode manter logs técnicos mínimos para segurança, disponibilidade e diagnóstico.
Headers e transporte
HTTPS, HSTS, CSP, X-Frame-Options, nosniff, Referrer-Policy e Permissions-Policy são validados por smoke tests live quando o certificado do ambiente o permite.
CI/CD e supply chain
O pipeline corre build, CodeQL, guard no-capture e smoke tests de artefacto. Dependências e configurações geradas pelo Lovable só são aceitáveis quando não ficam importadas nem alcançáveis no runtime.
trust center
supply-chain policy
Dependências e artefactos
O site público é entregue como artefacto estático. Dependências, imports e endpoints de captura são tratados como superfície de supply chain: o CI bloqueia imports Supabase/captcha/contacto, corre CodeQL, build e smoke tests de artefacto. SBOM, SCA formal e assinaturas são exigências de release/enterprise quando o escopo as ativa.
Grounding SbD-ToE: DST-001..DST-006, CFG-001..CFG-006, ART-sbom, ART-sca-report, ART-artifact-provenance.
release integrity
Integridade de release
Cada alteração pública é rastreável a Git commit e execução de GitHub Actions. O output publicado é estático; o host não precisa de runtime Node para servir o site. Para releases do MCP, a proveniência pública passa por npm, GitHub e histórico versionado do repositório.
Estado atual: commits, tags de rollback, CI logs, artefacto estático e smoke tests. Assinaturas/attestations formais não são apresentadas como implementadas quando não existem.
vulnerability handling
Tratamento de vulnerabilidades
Relatórios acionáveis são triados por impacto, explorabilidade e superfície afetada. Objetivo público: acusar receção em até 5 dias úteis e dar triagem inicial em até 10 dias úteis quando o relatório inclui reprodução suficiente. Prazos contratuais prevalecem em trabalho enterprise.
Canal público: security.txt e canais profissionais diretos. Divulgação coordenada antes de publicar detalhes exploráveis.
licenses & provenance
Licenças e proveniência
Código/runtime open source usa Apache-2.0. Conteúdo de manual e snapshots seguem CC BY-SA 4.0 quando indicado. DOI, GitHub, npm e IDs citáveis servem rastreabilidade técnica; não transformam automaticamente evidência técnica em veredito regulatório.
Linha que não atravessamos: cross-check técnico, não declaração de conformidade.
responsible disclosure
Como reportar um problema.
- Reporte vulnerabilidades de forma privada por canais profissionais diretos ou LinkedIn.
- Não publique detalhes exploráveis em issues públicas antes de haver correção ou mitigação.
- Não execute testes destrutivos, DDoS, engenharia social, phishing, spam ou exfiltração de dados.
- Inclua URL afetado, passos de reprodução, impacto esperado e qualquer evidência mínima necessária.
- Não existe programa público de bug bounty. SLAs contratuais existem apenas quando definidos em trabalho enterprise.
evidence model
Como classificamos afirmações.
Manual-grounded
Derivado do SbD-ToE/MCP: requisitos, controlos, artefactos e IDs citáveis.
Observed
Visível no repositório, CI, artefacto publicado, headers, rotas ou ficheiros públicos.
Inferred
Conclusão lógica a partir de factos observados; nunca apresentada como controlo implementado.
Not verified
Ponto não confirmado ou dependente de ambiente/contrato; fica explicitamente marcado.
enterprise boundary
O site público não é o ambiente dos clientes.
O SbD-ToE público, o MCP open source e este site não processam dados de cliente. Em trabalho enterprise, o Knowledge Graph privado, os snapshots, os logs e as credenciais são definidos por contrato, arquitetura e boundary operacional do cliente.
A tese é simples: conhecimento de segurança governado, rastreável e acionável no ponto de mudança, sem transformar o site público num ponto de recolha.
Ver privacidadeVer termos