@shiftleftpt/sbd-toe-mcp 0.20.0-beta.44 → 0.20.0-beta.46
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/consumed-bundle.json +10 -10
- package/data/entities/proportionality.json +3 -3
- package/data/entities/sdlc_integration.json +885 -4
- package/data/publish/indexes/canonical_chunks.jsonl +4907 -4907
- package/data/publish/indexes/mcp_chunks.jsonl +38 -38
- package/data/publish/indexes/publication_manifest.json +3 -3
- package/data/publish/ontology/sbdtoe-ontology.yaml +20 -5
- package/data/publish/runtime/assignments.json +2034 -376
- package/data/publish/runtime/decision_involvements.json +17 -5
- package/data/publish/runtime/deterministic_manifest.json +3 -3
- package/data/publish/runtime/phases.json +8 -6
- package/data/publish/runtime/user_stories.json +54 -27
- package/data/publish/runtime/v1/manual_maturity_progression.jsonl +336 -336
- package/data/publish/runtime/v1/manual_rastreabilidade.jsonl +1105 -1105
- package/data/publish/runtime/v1/manual_threat_mitigation.jsonl +523 -523
- package/data/publish/runtime/v1/v1_manifest.json +5 -5
- package/data/publish/semantic/macro_processes.jsonl +1 -1
- package/data/publish/semantic/mp_edges.jsonl +1 -1
- package/data/reports/run_manifest.json +8 -8
- package/dist/index.js +15 -6
- package/dist/index.js.map +1 -1
- package/dist/serving/agent-guide.js +9 -0
- package/dist/serving/agent-guide.js.map +1 -1
- package/dist/serving/declared-absences.d.ts +16 -0
- package/dist/serving/declared-absences.js +17 -2
- package/dist/serving/declared-absences.js.map +1 -1
- package/dist/tools/get-chapter-capability.js +30 -7
- package/dist/tools/get-chapter-capability.js.map +1 -1
- package/dist/tools/get-guide-by-role.js +33 -0
- package/dist/tools/get-guide-by-role.js.map +1 -1
- package/dist/tools/get-macro-processes.js +2 -1
- package/dist/tools/get-macro-processes.js.map +1 -1
- package/dist/tools/map-review-scope.d.ts +2 -0
- package/dist/tools/map-review-scope.js +18 -0
- package/dist/tools/map-review-scope.js.map +1 -1
- package/dist/tools/plan-repo-governance.d.ts +2 -0
- package/dist/tools/plan-repo-governance.js +18 -0
- package/dist/tools/plan-repo-governance.js.map +1 -1
- package/dist/tools/plan-rollout.js +33 -3
- package/dist/tools/plan-rollout.js.map +1 -1
- package/dist/tools/trace-graph.d.ts +3 -0
- package/dist/tools/trace-graph.js +5 -0
- package/dist/tools/trace-graph.js.map +1 -1
- package/dist/version-info.d.ts +9 -0
- package/dist/version-info.js +11 -0
- package/dist/version-info.js.map +1 -1
- package/package.json +1 -1
|
@@ -1701,9 +1701,9 @@
|
|
|
1701
1701
|
{"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--quem-executa-cada-acao", "chunk_kind": "table_section", "document_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_kind": "table_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["develop"], "risk_level": []}, "mentioned_entities": {}, "record_id": "mcp::010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--quem-executa-cada-acao", "relation_hints": [], "section_path": ["Aplicação no Ciclo de Vida - Dependências, SBOM e SCA", "👥 Quem executa cada ação"], "size_estimate": {"approx_tokens": 173, "chars": 690}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## 👥 Quem executa cada ação\n\nA governação é **coletiva** - papéis e responsabilidades consistentes com o intro.md.\n\n| Papel | Responsabilidade |\n|------|-------------------|\n| **Developer / Lead** | Incluir dependências, triagem inicial, *pinning*, correções |\n| **AppSec Engineer** | Políticas, *tuning* de *gates*, gestão de exceções e risco |\n| **DevOps / CI/CD** | SBOM, SCA, repositórios internos, bots de atualização e *impact analysis* |\n| **QA** | Evidências, testes de regressão, validação de PRs de bots |\n| **Product Owner** | Decisão *go/no-go* e aceitação de risco residual |\n| **GRC / Gestão** | Auditoria, conformidade, retenção de evidências |\n\n---", "title": "👥 Quem executa cada ação", "traceability": {"line_end": 41, "line_start": 27, "source_path": "010-sbd-manual/05-dependencias-sbom-sca/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--quem-executa-cada-acao"}, "vector_text": "👥 Quem executa cada ação\n\n## 👥 Quem executa cada ação\n\nA governação é **coletiva** - papéis e responsabilidades consistentes com o intro.md.\n\n| Papel | Responsabilidade |\n|------|-------------------|\n| **Developer / Lead** | Incluir dependências, triagem inicial, *pinning*, correções |\n| **AppSec Engineer** | Políticas, *tuning* de *gates*, gestão de exceções e risco |\n| **DevOps / CI/CD** | SBOM, SCA, repositórios internos, bots de atualização e *impact analysis* |\n| **QA** | Evidências, testes de regressão, validação de PRs de bots |\n| **Product Owner** | Decisão *go/no-go* e aceitação de risco residual |\n| **GRC / Gestão** | Auditoria, conformidade, retenção de evidências |\n\n---"}
|
|
1702
1702
|
{"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis", "chunk_kind": "narrative_section", "document_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_kind": "narrative_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["develop"], "risk_level": []}, "mentioned_entities": {}, "record_id": "mcp::010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis", "relation_hints": [], "section_path": ["Aplicação no Ciclo de Vida - Dependências, SBOM e SCA", "📖 User Stories Reutilizáveis"], "size_estimate": {"approx_tokens": 59, "chars": 234}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## 📖 User Stories Reutilizáveis\n\nCada US transforma a prescrição em backlog acionável, com **contexto, rationale científico, BDD/checklist, artefactos, proporcionalidade L1–L3 e integração no SDLC**.\n\n---", "title": "📖 User Stories Reutilizáveis", "traceability": {"line_end": 47, "line_start": 42, "source_path": "010-sbd-manual/05-dependencias-sbom-sca/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis"}, "vector_text": "📖 User Stories Reutilizáveis\n\n## 📖 User Stories Reutilizáveis\n\nCada US transforma a prescrição em backlog acionável, com **contexto, rationale científico, BDD/checklist, artefactos, proporcionalidade L1–L3 e integração no SDLC**.\n\n---"}
|
|
1703
1703
|
{"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-01-gestao-de-dependencias-seguras", "chunk_kind": "user_story", "document_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["develop"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-01"]}, "record_id": "mcp::010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-01-gestao-de-dependencias-seguras", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação no Ciclo de Vida - Dependências, SBOM e SCA", "📖 User Stories Reutilizáveis", "US-01 - Gestão de dependências seguras"], "size_estimate": {"approx_tokens": 353, "chars": 1412}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-01 - Gestão de dependências seguras\n\n**Contexto.** \nDependências externas sem validação introduzem risco invisível (componentes abandonados, origem duvidosa, licenças incompatíveis).\n\n:::userstory\n**História.** \nComo **Developer**, quero **usar apenas dependências aprovadas**, para **reduzir risco de vulnerabilidades herdadas e conflitos de licença**.\n\n**Critérios de aceitação (BDD).**\n- **Dado** que pretendo incluir uma dependência\n **Quando** submeto pedido de aprovação\n **Então** a dependência é validada segundo a política (origem, licença, manutenção, CVEs)\n\n**Checklist.**\n- [ ] Dependência aprovada formalmente \n- [ ] Licença validada / compatível \n- [ ] Sem CVEs críticos conhecidos \n- [ ] Proveniência confirmada (repositório interno)\n\n:::\n\n**Artefactos & evidências.**\n- `dependencies-approval.md` \n- Ticket de validação no backlog\n\n**Proporcionalidade por risco.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Opcional | Aprovação simplificada |\n| L2 | Sim | Validação formal + licença |\n| L3 | Sim | Revisão AppSec + proveniência\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Design/Dev | Inclusão de dependência | Developer + AppSec | Na aprovação da dependência |\n\n**Ligações úteis.** \n- [Pilares de governação](/sbd-toe/sbd-manual/dependencias-sbom-sca/intro#pilares-de-governação)\n\n---", "title": "US-01 - Gestão de dependências seguras", "traceability": {"line_end": 90, "line_start": 48, "source_path": "010-sbd-manual/05-dependencias-sbom-sca/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-01-gestao-de-dependencias-seguras"}, "vector_text": "US-01 - Gestão de dependências seguras\n\n### US-01 - Gestão de dependências seguras\n\n**Contexto.** \nDependências externas sem validação introduzem risco invisível (componentes abandonados, origem duvidosa, licenças incompatíveis).\n\n:::userstory\n**História.** \nComo **Developer**, quero **usar apenas dependências aprovadas**, para **reduzir risco de vulnerabilidades herdadas e conflitos de licença**.\n\n**Critérios de aceitação (BDD).**\n- **Dado** que pretendo incluir uma dependência\n **Quando** submeto pedido de aprovação\n **Então** a dependência é validada segundo a política (origem, licença, manutenção, CVEs)\n\n**Checklist.**\n- [ ] Dependência aprovada formalmente \n- [ ] Licença validada / compatível \n- [ ] Sem CVEs críticos conhecidos \n- [ ] Proveniência confirmada (repositório interno)\n\n:::\n\n**Artefactos & evidências.**\n- `dependencies-approval.md` \n- Ticket de validação no backlog\n\n**Proporcionalidade por risco.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Opcional | Aprovação simplificada |\n| L2 | Sim | Validação formal + licença |\n| L3 | Sim | Revisão AppSec + proveniência\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Design/Dev | Inclusão de dependência | Developer + AppSec | Na aprovação da dependência |\n\n**Ligações úteis.** \n- [Pilares de governação](/sbd-toe/sbd-manual/dependencias-sbom-sca/intro#pilares-de-governação)\n\n---"}
|
|
1704
|
-
{"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-02-sbom-em-cada-build", "chunk_kind": "user_story", "document_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["develop"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-02", "US-10"]}, "record_id": "mcp::010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-02-sbom-em-cada-build", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação no Ciclo de Vida - Dependências, SBOM e SCA", "📖 User Stories Reutilizáveis", "US-02 - SBOM em cada build"], "size_estimate": {"approx_tokens":
|
|
1704
|
+
{"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-02-sbom-em-cada-build", "chunk_kind": "user_story", "document_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["develop"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-02", "US-10"]}, "record_id": "mcp::010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-02-sbom-em-cada-build", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação no Ciclo de Vida - Dependências, SBOM e SCA", "📖 User Stories Reutilizáveis", "US-02 - SBOM em cada build"], "size_estimate": {"approx_tokens": 332, "chars": 1326}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-02 - SBOM em cada build\n\n**Contexto.** \nSem SBOM atualizado não é possível determinar rapidamente exposição a CVEs e cumprir requisitos de auditoria.\n\n:::userstory\n**História.** \nComo **DevOps / SRE**, quero **gerar SBOM em cada build**, para **rastreabilidade completa de componentes**.\n\n**Critérios de aceitação (BDD).**\n- **Dado** que um build é acionado\n **Quando** o artefacto é produzido\n **Então** é gerado um SBOM em formato CycloneDX ou SPDX\n\n- **Dado** um SBOM gerado\n- **Quando** é associado à release\n- **Então** é armazenado e acessível para auditoria\n\n**Checklist.**\n- [ ] SBOM no formato CycloneDX ou SPDX \n- [ ] SBOM versionado e associado à release \n- [ ] Acessível para auditoria\n\n:::\n\n**Artefactos & evidências.**\n- `sbom.json` / `sbom.xml`\n\n**Proporcionalidade por risco.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Sim | SBOM básico |\n| L2 | Sim | SBOM completo, incluído na release |\n| L3 | Sim | SBOM assinado + verificação de integridade\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| CI | Execução de build | DevOps | Conforme ciclo da US |\n\n**Ligações úteis.** \n- [SBOM - Normas CycloneDX e SPDX](https://www.cyclonedx.org)\n- [US-10 - Inventário e SBOM por Build](#us-10---inventário-e-sbom-por-build)\n\n---", "title": "US-02 - SBOM em cada build", "traceability": {"line_end": 136, "line_start": 91, "source_path": "010-sbd-manual/05-dependencias-sbom-sca/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-02-sbom-em-cada-build"}, "vector_text": "US-02 - SBOM em cada build\n\n### US-02 - SBOM em cada build\n\n**Contexto.** \nSem SBOM atualizado não é possível determinar rapidamente exposição a CVEs e cumprir requisitos de auditoria.\n\n:::userstory\n**História.** \nComo **DevOps / SRE**, quero **gerar SBOM em cada build**, para **rastreabilidade completa de componentes**.\n\n**Critérios de aceitação (BDD).**\n- **Dado** que um build é acionado\n **Quando** o artefacto é produzido\n **Então** é gerado um SBOM em formato CycloneDX ou SPDX\n\n- **Dado** um SBOM gerado\n- **Quando** é associado à release\n- **Então** é armazenado e acessível para auditoria\n\n**Checklist.**\n- [ ] SBOM no formato CycloneDX ou SPDX \n- [ ] SBOM versionado e associado à release \n- [ ] Acessível para auditoria\n\n:::\n\n**Artefactos & evidências.**\n- `sbom.json` / `sbom.xml`\n\n**Proporcionalidade por risco.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Sim | SBOM básico |\n| L2 | Sim | SBOM completo, incluído na release |\n| L3 | Sim | SBOM assinado + verificação de integridade\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| CI | Execução de build | DevOps | Conforme ciclo da US |\n\n**Ligações úteis.** \n- [SBOM - Normas CycloneDX e SPDX](https://www.cyclonedx.org)\n- [US-10 - Inventário e SBOM por Build](#us-10---inventário-e-sbom-por-build)\n\n---"}
|
|
1705
1705
|
{"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-03-sca-automatico-com-gates", "chunk_kind": "user_story", "document_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["develop"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-03"]}, "record_id": "mcp::010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-03-sca-automatico-com-gates", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação no Ciclo de Vida - Dependências, SBOM e SCA", "📖 User Stories Reutilizáveis", "US-03 - SCA automático com *gates*"], "size_estimate": {"approx_tokens": 314, "chars": 1256}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-03 - SCA automático com *gates*\n\n**Contexto.** \nSCA identifica vulnerabilidades conhecidas em dependências (diretas e transitivas) e deve bloquear risco inaceitável.\n\n:::userstory\n**História.** \nComo **AppSec Engineer**, quero **executar SCA automático nos pipelines**, para **detetar CVEs antes de produção**.\n\n**Critérios de aceitação (BDD).**\n- **Dado** um build\n **Quando** o SBOM é gerado\n **Então** o SCA corre e **bloqueia** findings que excedam o threshold por Lx\n\n**Checklist.**\n- [ ] Scanner SCA integrado (ex.: Dependency‑Check/Trivy/Grype) \n- [ ] Findings documentados e triados \n- [ ] Bloqueio automático para CVEs críticos (L2) e médios+ (L3)\n\n:::\n\n**Artefactos & evidências.**\n- `sca-report.html` / JSON\n- Logs de pipeline com *gates*\n\n**Proporcionalidade por risco.**\n| Nível | Política |\n|---|---|\n| L1 | Alerta |\n| L2 | Bloqueio High/Critical |\n| L3 | Bloqueio Medium+\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| CI | Geração de SBOM | DevOps + AppSec | Durante o build (bloqueio imediato) |\n\n**Ligações úteis.** \n- [Guia de thresholds por L1–L3](/sbd-toe/sbd-manual/dependencias-sbom-sca/aplicacao-lifecycle#matriz-de-proporcionalidade-l1l3)\n\n---", "title": "US-03 - SCA automático com *gates*", "traceability": {"line_end": 178, "line_start": 137, "source_path": "010-sbd-manual/05-dependencias-sbom-sca/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-03-sca-automatico-com-gates"}, "vector_text": "US-03 - SCA automático com *gates*\n\n### US-03 - SCA automático com *gates*\n\n**Contexto.** \nSCA identifica vulnerabilidades conhecidas em dependências (diretas e transitivas) e deve bloquear risco inaceitável.\n\n:::userstory\n**História.** \nComo **AppSec Engineer**, quero **executar SCA automático nos pipelines**, para **detetar CVEs antes de produção**.\n\n**Critérios de aceitação (BDD).**\n- **Dado** um build\n **Quando** o SBOM é gerado\n **Então** o SCA corre e **bloqueia** findings que excedam o threshold por Lx\n\n**Checklist.**\n- [ ] Scanner SCA integrado (ex.: Dependency‑Check/Trivy/Grype) \n- [ ] Findings documentados e triados \n- [ ] Bloqueio automático para CVEs críticos (L2) e médios+ (L3)\n\n:::\n\n**Artefactos & evidências.**\n- `sca-report.html` / JSON\n- Logs de pipeline com *gates*\n\n**Proporcionalidade por risco.**\n| Nível | Política |\n|---|---|\n| L1 | Alerta |\n| L2 | Bloqueio High/Critical |\n| L3 | Bloqueio Medium+\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| CI | Geração de SBOM | DevOps + AppSec | Durante o build (bloqueio imediato) |\n\n**Ligações úteis.** \n- [Guia de thresholds por L1–L3](/sbd-toe/sbd-manual/dependencias-sbom-sca/aplicacao-lifecycle#matriz-de-proporcionalidade-l1l3)\n\n---"}
|
|
1706
|
-
{"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-04-excecoes-a-cves-formais-e-temporarias", "chunk_kind": "user_story", "document_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["develop"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-01", "US-04"]}, "record_id": "mcp::010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-04-excecoes-a-cves-formais-e-temporarias", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação no Ciclo de Vida - Dependências, SBOM e SCA", "📖 User Stories Reutilizáveis", "US-04 - Exceções a CVEs formais e temporárias"], "size_estimate": {"approx_tokens":
|
|
1706
|
+
{"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-04-excecoes-a-cves-formais-e-temporarias", "chunk_kind": "user_story", "document_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["develop"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-01", "US-04"]}, "record_id": "mcp::010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-04-excecoes-a-cves-formais-e-temporarias", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação no Ciclo de Vida - Dependências, SBOM e SCA", "📖 User Stories Reutilizáveis", "US-04 - Exceções a CVEs formais e temporárias"], "size_estimate": {"approx_tokens": 458, "chars": 1831}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-04 - Exceções a CVEs formais e temporárias\n\n**Contexto.** \nNem todos os findings podem ser resolvidos de imediato; exceções devem ser **formais, justificadas e temporárias**.\n\n:::userstory\n**História.** \nComo **AppSec Engineer**, quero **formalizar exceções a CVEs**, para **manter governação e justificar risco residual**.\n\n**Critérios de aceitação (BDD).**\n- **Dado** que existe um CVE não resolvido\n **Quando** é solicitada uma exceção\n **Então** a exceção é formalizada em `excecoes.yaml` com justificativa técnica e de negócio, aprovador e prazo\n\n- **Dado** uma exceção com prazo definido\n- **Quando** passa o prazo\n- **Então** é acionada revisão periódica com reavaliação do risco\n\n**Checklist.**\n- [ ] `excecoes.yaml` com justificativa técnica e de negócio \n- [ ] Aprovador e prazo definidos \n- [ ] Controlo compensatório especificado \n- [ ] Revisão periódica agendada\n\n:::\n\n**Artefactos & evidências.**\n- `excecoes.yaml` (versionado)\n- Aprovação registada no backlog\n\n> **Referência:** Este US implementa [Cap 14-US-01: Processo formal de exceções]\n> no contexto de vulnerabilidades em dependências (CVEs). O processo de aprovação, TTL e revalidação devem seguir a política master de exceções em Cap 14.\n\n**Proporcionalidade por risco.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Opcional | Justificação simples |\n| L2 | Sim | Revisão periódica (30–90 dias) |\n| L3 | Sim | Validação executiva + métricas de risco\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Release | Findings pendentes | AppSec + Product Owner | Conforme prazo definido na exceção |\n\n**Ligações úteis.** \n- [Exceções e Aceitação de Risco em Vulnerabilidades](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/excecoes-e-aceitacao-risco)\n\n---", "title": "US-04 - Exceções a CVEs formais e temporárias", "traceability": {"line_end": 228, "line_start": 179, "source_path": "010-sbd-manual/05-dependencias-sbom-sca/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-04-excecoes-a-cves-formais-e-temporarias"}, "vector_text": "US-04 - Exceções a CVEs formais e temporárias\n\n### US-04 - Exceções a CVEs formais e temporárias\n\n**Contexto.** \nNem todos os findings podem ser resolvidos de imediato; exceções devem ser **formais, justificadas e temporárias**.\n\n:::userstory\n**História.** \nComo **AppSec Engineer**, quero **formalizar exceções a CVEs**, para **manter governação e justificar risco residual**.\n\n**Critérios de aceitação (BDD).**\n- **Dado** que existe um CVE não resolvido\n **Quando** é solicitada uma exceção\n **Então** a exceção é formalizada em `excecoes.yaml` com justificativa técnica e de negócio, aprovador e prazo\n\n- **Dado** uma exceção com prazo definido\n- **Quando** passa o prazo\n- **Então** é acionada revisão periódica com reavaliação do risco\n\n**Checklist.**\n- [ ] `excecoes.yaml` com justificativa técnica e de negócio \n- [ ] Aprovador e prazo definidos \n- [ ] Controlo compensatório especificado \n- [ ] Revisão periódica agendada\n\n:::\n\n**Artefactos & evidências.**\n- `excecoes.yaml` (versionado)\n- Aprovação registada no backlog\n\n> **Referência:** Este US implementa [Cap 14-US-01: Processo formal de exceções]\n> no contexto de vulnerabilidades em dependências (CVEs). O processo de aprovação, TTL e revalidação devem seguir a política master de exceções em Cap 14.\n\n**Proporcionalidade por risco.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Opcional | Justificação simples |\n| L2 | Sim | Revisão periódica (30–90 dias) |\n| L3 | Sim | Validação executiva + métricas de risco\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Release | Findings pendentes | AppSec + Product Owner | Conforme prazo definido na exceção |\n\n**Ligações úteis.** \n- [Exceções e Aceitação de Risco em Vulnerabilidades](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/excecoes-e-aceitacao-risco)\n\n---"}
|
|
1707
1707
|
{"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-05-validacao-de-release-go-no-go", "chunk_kind": "user_story", "document_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["develop"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-05"]}, "record_id": "mcp::010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-05-validacao-de-release-go-no-go", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação no Ciclo de Vida - Dependências, SBOM e SCA", "📖 User Stories Reutilizáveis", "US-05 - Validação de release (*go/no-go*)"], "size_estimate": {"approx_tokens": 340, "chars": 1359}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-05 - Validação de release (*go/no-go*)\n\n**Contexto.** \nCada release é uma decisão de risco que deve ser **explícita e rastreável**.\n\n:::userstory\n**História.** \nComo **Product Owner**, quero **validar findings e exceções antes do go‑live**, para **tomar decisão informada de *go/no-go***.\n\n**Critérios de aceitação (BDD).**\n- **Dado** uma release candidata\n **Quando** verifico critérios de segurança e risco residual\n **Então** documento a decisão e condicionantes (se existirem)\n\n**Checklist.**\n- [ ] Lista de findings e estado \n- [ ] Exceções aprovadas e válidas \n- [ ] Decisão *go/no-go* documentada\n\n:::\n\n**Artefactos & evidências.**\n- `releases.md` com histórico e justificações\n\n**Proporcionalidade por risco.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Opcional | Decisão simples |\n| L2 | Sim | Revisão formal |\n| L3 | Sim | Revisão formal + AppSec envolvido\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Pré‑release | RC pronta | Product Owner + QA + AppSec | Antes do deploy a produção |\n\n**Ligações úteis.** \n<!-- genia_suggest: Criar addon/10-checklist-release-segura.md com checklist de validação de release por L1-L3 -->\n- [Artefactos esperados](/sbd-toe/sbd-manual/dependencias-sbom-sca/aplicacao-lifecycle#-artefactos-esperados)\n\n---", "title": "US-05 - Validação de release (*go/no-go*)", "traceability": {"line_end": 270, "line_start": 229, "source_path": "010-sbd-manual/05-dependencias-sbom-sca/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-05-validacao-de-release-go-no-go"}, "vector_text": "US-05 - Validação de release (*go/no-go*)\n\n### US-05 - Validação de release (*go/no-go*)\n\n**Contexto.** \nCada release é uma decisão de risco que deve ser **explícita e rastreável**.\n\n:::userstory\n**História.** \nComo **Product Owner**, quero **validar findings e exceções antes do go‑live**, para **tomar decisão informada de *go/no-go***.\n\n**Critérios de aceitação (BDD).**\n- **Dado** uma release candidata\n **Quando** verifico critérios de segurança e risco residual\n **Então** documento a decisão e condicionantes (se existirem)\n\n**Checklist.**\n- [ ] Lista de findings e estado \n- [ ] Exceções aprovadas e válidas \n- [ ] Decisão *go/no-go* documentada\n\n:::\n\n**Artefactos & evidências.**\n- `releases.md` com histórico e justificações\n\n**Proporcionalidade por risco.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Opcional | Decisão simples |\n| L2 | Sim | Revisão formal |\n| L3 | Sim | Revisão formal + AppSec envolvido\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Pré‑release | RC pronta | Product Owner + QA + AppSec | Antes do deploy a produção |\n\n**Ligações úteis.** \n<!-- genia_suggest: Criar addon/10-checklist-release-segura.md com checklist de validação de release por L1-L3 -->\n- [Artefactos esperados](/sbd-toe/sbd-manual/dependencias-sbom-sca/aplicacao-lifecycle#-artefactos-esperados)\n\n---"}
|
|
1708
1708
|
{"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-06-repositorios-internos-como-fonte-unica", "chunk_kind": "user_story", "document_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["develop"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-06"]}, "record_id": "mcp::010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-06-repositorios-internos-como-fonte-unica", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação no Ciclo de Vida - Dependências, SBOM e SCA", "📖 User Stories Reutilizáveis", "US-06 - Repositórios internos como fonte única"], "size_estimate": {"approx_tokens": 317, "chars": 1266}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-06 - Repositórios internos como fonte única\n\n**Contexto.** \nSem repositórios internos, dependências podem ser resolvidas de fontes não controladas (*typosquatting*, *confusion*, malícia).\n\n:::userstory\n**História.** \nComo **DevOps / SRE**, quero ***enforce* repositórios internos aprovados**, para **garantir proveniência e consistência**.\n\n**Critérios de aceitação (BDD).**\n- **Dado** que o *package manager* resolve dependências\n **Quando** a build ocorre\n **Então** só aceita fontes do repositório interno aprovado\n\n**Checklist.**\n- [ ] `repo-config.yaml` ativo (proxy/registry interno) \n- [ ] Bloqueio a fontes externas (allowlist) \n- [ ] Logs de acesso monitorizados e retidos\n\n:::\n\n**Artefactos & evidências.**\n- `repo-config.yaml` \n- Logs de CI/CD com origem validada\n\n**Proporcionalidade por risco.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Opcional | Recomendado |\n| L2 | Sim | Obrigatório |\n| L3 | Sim | Obrigatório + assinatura/verificação de pacotes\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Build | Resolução de dependências | DevOps/CI | Imediato (bloqueio em tempo real) |\n\n**Ligações úteis.** \n- SLSA Provenance (conceitos)\n\n---", "title": "US-06 - Repositórios internos como fonte única", "traceability": {"line_end": 312, "line_start": 271, "source_path": "010-sbd-manual/05-dependencias-sbom-sca/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-06-repositorios-internos-como-fonte-unica"}, "vector_text": "US-06 - Repositórios internos como fonte única\n\n### US-06 - Repositórios internos como fonte única\n\n**Contexto.** \nSem repositórios internos, dependências podem ser resolvidas de fontes não controladas (*typosquatting*, *confusion*, malícia).\n\n:::userstory\n**História.** \nComo **DevOps / SRE**, quero ***enforce* repositórios internos aprovados**, para **garantir proveniência e consistência**.\n\n**Critérios de aceitação (BDD).**\n- **Dado** que o *package manager* resolve dependências\n **Quando** a build ocorre\n **Então** só aceita fontes do repositório interno aprovado\n\n**Checklist.**\n- [ ] `repo-config.yaml` ativo (proxy/registry interno) \n- [ ] Bloqueio a fontes externas (allowlist) \n- [ ] Logs de acesso monitorizados e retidos\n\n:::\n\n**Artefactos & evidências.**\n- `repo-config.yaml` \n- Logs de CI/CD com origem validada\n\n**Proporcionalidade por risco.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Opcional | Recomendado |\n| L2 | Sim | Obrigatório |\n| L3 | Sim | Obrigatório + assinatura/verificação de pacotes\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Build | Resolução de dependências | DevOps/CI | Imediato (bloqueio em tempo real) |\n\n**Ligações úteis.** \n- SLSA Provenance (conceitos)\n\n---"}
|
|
1709
1709
|
{"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-07-proibir-bibliotecas-copiadas-manualmente", "chunk_kind": "user_story", "document_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "05-dependencias-sbom-sca", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["develop"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-07"]}, "record_id": "mcp::010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-07-proibir-bibliotecas-copiadas-manualmente", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação no Ciclo de Vida - Dependências, SBOM e SCA", "📖 User Stories Reutilizáveis", "US-07 - Proibir bibliotecas copiadas manualmente"], "size_estimate": {"approx_tokens": 371, "chars": 1484}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-07 - Proibir bibliotecas copiadas manualmente\n\n**Contexto.** \nJS, PHP, DLLs, JARs copiados diretamente para o repo escapam ao SBOM e ao SCA, criando *shadow dependencies*.\n\n:::userstory\n**História.** \nComo **Developer**, quero **usar apenas *package managers*/repositórios internos**, **nunca** copiar bibliotecas para o repo.\n\n**Critérios de aceitação (BDD).**\n- **Dado** que preciso de uma biblioteca externa\n **Quando** a adiciono ao projeto\n **Então** é gerida via *package manager* e **não** por cópia manual\n\n**Checklist.**\n- [ ] Zero libs copiadas manualmente \n- [ ] Todas via *package manager* \n- [ ] Auditoria periódica confirma ausência\n\n:::\n\n**Artefactos & evidências.**\n- `package.json` / `pom.xml` / `composer.json` \n- Logs de build (resolução via repos internos)\n\n**Proporcionalidade por risco.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Sim | Política documentada |\n| L2 | Sim | Auditorias periódicas |\n| L3 | Sim | Enforcement automático em CI/CD\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Dev | Inclusão de nova lib | Developer + AppSec | Na aprovação da dependência |\n\n**Ligações úteis.** \n<!-- genia_suggest: Criar addon/11-bibliotecas-locais-migracao.md com padrões de migração por stack (npm, maven, composer, etc) -->\n- [Governança de Bibliotecas de Terceiros](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/governanca-libs-terceiros)\n\n---", "title": "US-07 - Proibir bibliotecas copiadas manualmente", "traceability": {"line_end": 355, "line_start": 313, "source_path": "010-sbd-manual/05-dependencias-sbom-sca/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-05-dependencias-sbom-sca-aplicacao-lifecycle--aplicacao-no-ciclo-de-vida-dependencias-sbom-e-sca--user-stories-reutilizaveis--us-07-proibir-bibliotecas-copiadas-manualmente"}, "vector_text": "US-07 - Proibir bibliotecas copiadas manualmente\n\n### US-07 - Proibir bibliotecas copiadas manualmente\n\n**Contexto.** \nJS, PHP, DLLs, JARs copiados diretamente para o repo escapam ao SBOM e ao SCA, criando *shadow dependencies*.\n\n:::userstory\n**História.** \nComo **Developer**, quero **usar apenas *package managers*/repositórios internos**, **nunca** copiar bibliotecas para o repo.\n\n**Critérios de aceitação (BDD).**\n- **Dado** que preciso de uma biblioteca externa\n **Quando** a adiciono ao projeto\n **Então** é gerida via *package manager* e **não** por cópia manual\n\n**Checklist.**\n- [ ] Zero libs copiadas manualmente \n- [ ] Todas via *package manager* \n- [ ] Auditoria periódica confirma ausência\n\n:::\n\n**Artefactos & evidências.**\n- `package.json` / `pom.xml` / `composer.json` \n- Logs de build (resolução via repos internos)\n\n**Proporcionalidade por risco.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Sim | Política documentada |\n| L2 | Sim | Auditorias periódicas |\n| L3 | Sim | Enforcement automático em CI/CD\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Dev | Inclusão de nova lib | Developer + AppSec | Na aprovação da dependência |\n\n**Ligações úteis.** \n<!-- genia_suggest: Criar addon/11-bibliotecas-locais-migracao.md com padrões de migração por stack (npm, maven, composer, etc) -->\n- [Governança de Bibliotecas de Terceiros](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/governanca-libs-terceiros)\n\n---"}
|
|
@@ -2926,16 +2926,16 @@
|
|
|
2926
2926
|
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-10-deploy-progressivo-com-estrategias-canary-blue-green", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-10"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-10-deploy-progressivo-com-estrategias-canary-blue-green", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📖 User Stories Reutilizáveis", "US-10 - *Deploy* progressivo com estratégias *canary*/*blue-green*"], "size_estimate": {"approx_tokens": 590, "chars": 2358}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-10 - *Deploy* progressivo com estratégias *canary*/*blue-green*\n\nPromover para 100% dos utilizadores simultaneamente amplifica o impacto de qualquer falha. Progressividade permite detetar regressões com risco controlado.\n\n**Contexto.** *Deploy* imediato para 100% aumenta a probabilidade de incidente generalizado.\n\n:::userstory\n**História.** \nComo **DevOps / SRE / Gestão Executiva**, quero **implementar *deploy* progressivo (*canary*, *blue/green*, regras por etapas)**, para **mitigar risco e permitir *rollback* rápido com impacto minimizado**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** uma *release* candidata com plano de *rollout* \n **Quando** inicio o *deploy* \n **Então** a versão é promovida gradualmente (ex.: 1% → 5% → 20% → 100%)\n\n- **Dado** que estou numa etapa de *rollout* \n **Quando** avalio métricas de sucesso (erros, latência, segurança) \n **Então** a promoção para a etapa seguinte só ocorre se critérios forem cumpridos; caso contrário, bloqueia ou reverte\n\n- **Dado** um critério de bloqueio acionado \n **Quando** o *threshold* é ultrapassado \n **Então** ocorre *rollback* automático ou é exigida decisão humana conforme criticidade\n\n**Checklist.** \n- [ ] Estratégia de *rollout* documentada (*canary* por percentagem ou *blue/green* por validação) \n- [ ] Métricas de sucesso por etapa definidas (baseline vs *canary*) \n- [ ] Critérios de bloqueio parametrizados (ex.: erro 5xx, latência, alertas) \n- [ ] Testes em *canary* validados antes de promoção geral \n- [ ] *Rollback* automático por *threshold* ou manual por *owner* \n- [ ] *Dashboard* de estado do *rollout* em tempo real \n- [ ] Papéis de decisão claros (quem aprova promoção entre etapas)\n:::\n\n**Artefactos & evidências.** Configuração de *rollout*, métricas baseline vs *canary*, logs de eventos, *dashboard* com estado.\n\n**Proporcionalidade L1–L3.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Recomendado (manual por etapas) | Automatizado com métricas | Automatizado + *rollback* por *threshold* |\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|------|---------|-------------|-----|\n| Deploy | Promoção a produção | DevOps + QA | Por etapa ≤ 30 min |\n\n**Ligações úteis.** [Monitorização & Operações](/sbd-toe/sbd-manual/monitorizacao-operacoes/intro)\n\n---", "title": "US-10 - *Deploy* progressivo com estratégias *canary*/*blue-green*", "traceability": {"line_end": 477, "line_start": 429, "source_path": "010-sbd-manual/11-deploy-seguro/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-10-deploy-progressivo-com-estrategias-canary-blue-green"}, "vector_text": "US-10 - *Deploy* progressivo com estratégias *canary*/*blue-green*\n\n### US-10 - *Deploy* progressivo com estratégias *canary*/*blue-green*\n\nPromover para 100% dos utilizadores simultaneamente amplifica o impacto de qualquer falha. Progressividade permite detetar regressões com risco controlado.\n\n**Contexto.** *Deploy* imediato para 100% aumenta a probabilidade de incidente generalizado.\n\n:::userstory\n**História.** \nComo **DevOps / SRE / Gestão Executiva**, quero **implementar *deploy* progressivo (*canary*, *blue/green*, regras por etapas)**, para **mitigar risco e permitir *rollback* rápido com impacto minimizado**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** uma *release* candidata com plano de *rollout* \n **Quando** inicio o *deploy* \n **Então** a versão é promovida gradualmente (ex.: 1% → 5% → 20% → 100%)\n\n- **Dado** que estou numa etapa de *rollout* \n **Quando** avalio métricas de sucesso (erros, latência, segurança) \n **Então** a promoção para a etapa seguinte só ocorre se critérios forem cumpridos; caso contrário, bloqueia ou reverte\n\n- **Dado** um critério de bloqueio acionado \n **Quando** o *threshold* é ultrapassado \n **Então** ocorre *rollback* automático ou é exigida decisão humana conforme criticidade\n\n**Checklist.** \n- [ ] Estratégia de *rollout* documentada (*canary* por percentagem ou *blue/green* por validação) \n- [ ] Métricas de sucesso por etapa definidas (baseline vs *canary*) \n- [ ] Critérios de bloqueio parametrizados (ex.: erro 5xx, latência, alertas) \n- [ ] Testes em *canary* validados antes de promoção geral \n- [ ] *Rollback* automático por *threshold* ou manual por *owner* \n- [ ] *Dashboard* de estado do *rollout* em tempo real \n- [ ] Papéis de decisão claros (quem aprova promoção entre etapas)\n:::\n\n**Artefactos & evidências.** Configuração de *rollout*, métricas baseline vs *canary*, logs de eventos, *dashboard* com estado.\n\n**Proporcionalidade L1–L3.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Recomendado (manual por etapas) | Automatizado com métricas | Automatizado + *rollback* por *threshold* |\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|------|---------|-------------|-----|\n| Deploy | Promoção a produção | DevOps + QA | Por etapa ≤ 30 min |\n\n**Ligações úteis.** [Monitorização & Operações](/sbd-toe/sbd-manual/monitorizacao-operacoes/intro)\n\n---"}
|
|
2927
2927
|
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-11-validacoes-tecnicas-pre-deploy-com-gates-condicionais", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-11"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-11-validacoes-tecnicas-pre-deploy-com-gates-condicionais", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📖 User Stories Reutilizáveis", "US-11 - Validações técnicas pré-deploy com *gates* condicionais"], "size_estimate": {"approx_tokens": 523, "chars": 2092}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-11 - Validações técnicas pré-deploy com *gates* condicionais\n\nSem validações estruturadas antes do *deploy*, código inseguro ou não funcional pode chegar a produção.\n\n**Contexto.** Validações inadequadas comprometem a integridade e elevam o risco operacional.\n\n:::userstory\n**História.** \nComo **AppSec/QA**, quero **executar validações técnicas (SAST, DAST, SBOM, análise de *findings*) com *gates* condicionais por risco**, para **bloquear automaticamente *releases* inseguras**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** uma *release* candidata \n **Quando** o pipeline de *deploy* inicia \n **Então** são executadas validações mínimas (SAST, DAST em *staging*, verificação de SBOM/dependências) e é produzido um relatório\n\n- **Dado** o resultado das validações \n **Quando** existem *findings* acima do limiar definido para Lx \n **Então** o *deploy* é bloqueado, exceto se existir exceção formal aprovada\n\n**Checklist.** \n- [ ] SAST configurado (ex.: SonarQube, Semgrep ou equivalente) \n- [ ] DAST autenticado em *staging* \n- [ ] SBOM gerado (CycloneDX/SPDX) e validado \n- [ ] Análise de dependências (CVE/licenciamento/políticas) \n- [ ] *Findings* com decisão justificada (aceite/mitigado/falso positivo) \n- [ ] *Gates* parametrizados por risco L1–L3 \n- [ ] Exceções registadas com *owner*, justificação e data de revisão/expiração \n- [ ] Relatório de validação anexado a cada *release*\n:::\n\n**Artefactos & evidências.** Relatórios SAST/DAST, SBOM, lista de *findings* com estado, logs de *gates* (bloqueios, aprovações, exceções), configuração de pipeline versionada.\n\n**Proporcionalidade L1–L3.** \n| L1 | L2 | L3 |\n|----|----|----|\n| SAST + aviso | SAST + DAST + bloqueio High/Critical | SAST + DAST + bloqueio Medium+ |\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|------|---------|-------------|-----|\n| Pré-release | Validação antes de produção | AppSec + DevOps | ≤ 30 min |\n\n**Ligações úteis.** [Testes de Segurança](/sbd-toe/sbd-manual/testes-seguranca/intro)\n\n---", "title": "US-11 - Validações técnicas pré-deploy com *gates* condicionais", "traceability": {"line_end": 523, "line_start": 478, "source_path": "010-sbd-manual/11-deploy-seguro/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-11-validacoes-tecnicas-pre-deploy-com-gates-condicionais"}, "vector_text": "US-11 - Validações técnicas pré-deploy com *gates* condicionais\n\n### US-11 - Validações técnicas pré-deploy com *gates* condicionais\n\nSem validações estruturadas antes do *deploy*, código inseguro ou não funcional pode chegar a produção.\n\n**Contexto.** Validações inadequadas comprometem a integridade e elevam o risco operacional.\n\n:::userstory\n**História.** \nComo **AppSec/QA**, quero **executar validações técnicas (SAST, DAST, SBOM, análise de *findings*) com *gates* condicionais por risco**, para **bloquear automaticamente *releases* inseguras**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** uma *release* candidata \n **Quando** o pipeline de *deploy* inicia \n **Então** são executadas validações mínimas (SAST, DAST em *staging*, verificação de SBOM/dependências) e é produzido um relatório\n\n- **Dado** o resultado das validações \n **Quando** existem *findings* acima do limiar definido para Lx \n **Então** o *deploy* é bloqueado, exceto se existir exceção formal aprovada\n\n**Checklist.** \n- [ ] SAST configurado (ex.: SonarQube, Semgrep ou equivalente) \n- [ ] DAST autenticado em *staging* \n- [ ] SBOM gerado (CycloneDX/SPDX) e validado \n- [ ] Análise de dependências (CVE/licenciamento/políticas) \n- [ ] *Findings* com decisão justificada (aceite/mitigado/falso positivo) \n- [ ] *Gates* parametrizados por risco L1–L3 \n- [ ] Exceções registadas com *owner*, justificação e data de revisão/expiração \n- [ ] Relatório de validação anexado a cada *release*\n:::\n\n**Artefactos & evidências.** Relatórios SAST/DAST, SBOM, lista de *findings* com estado, logs de *gates* (bloqueios, aprovações, exceções), configuração de pipeline versionada.\n\n**Proporcionalidade L1–L3.** \n| L1 | L2 | L3 |\n|----|----|----|\n| SAST + aviso | SAST + DAST + bloqueio High/Critical | SAST + DAST + bloqueio Medium+ |\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|------|---------|-------------|-----|\n| Pré-release | Validação antes de produção | AppSec + DevOps | ≤ 30 min |\n\n**Ligações úteis.** [Testes de Segurança](/sbd-toe/sbd-manual/testes-seguranca/intro)\n\n---"}
|
|
2928
2928
|
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-12-rollback-estruturado-por-tipo-binario-configuracao-bd-infra", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-12"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-12-rollback-estruturado-por-tipo-binario-configuracao-bd-infra", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📖 User Stories Reutilizáveis", "US-12 - *Rollback* estruturado por tipo (binário, configuração, BD, infra)"], "size_estimate": {"approx_tokens": 549, "chars": 2195}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-12 - *Rollback* estruturado por tipo (binário, configuração, BD, infra)\n\nNem todos os *rollbacks* são iguais. Sem plano específico por tipo, a reversão tende a ser manual, lenta e arriscada.\n\n**Contexto.** *Rollbacks* não planeados amplificam o tempo de recuperação e o risco de inconsistência.\n\n:::userstory\n**História.** \nComo **DevOps/SRE**, quero **documentar e testar *rollback* para cada tipo de alteração (binário, configuração, BD, infraestrutura)**, para **reverter incidentes rapidamente com confiança**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um incidente em produção \n **Quando** aciono *rollback* \n **Então** existe um procedimento aplicável ao tipo de alteração e fica evidência registada (quem, quando, versão alvo)\n\n- **Dado** uma alteração de BD ou infraestrutura \n **Quando** ocorre reversão \n **Então** existe controlo de consistência (migrações reversíveis/snapshots; estado IaC conhecido) e validação pós-*rollback*\n\n**Checklist.** \n- [ ] Plano de *rollback* por tipo documentado e revisto \n- [ ] *Rollback* binário: *tag* Git anterior identificada + testada \n- [ ] *Rollback* de configuração: *feature flags* / variáveis revertíveis \n- [ ] *Rollback* de BD: migração reversa ou *snapshot* testado \n- [ ] *Rollback* de infra: Terraform/Helm com estado conhecido e procedimento seguro \n- [ ] Testes de *rollback* executados trimestralmente (evidência) \n- [ ] SLA por tipo definido e comunicado \n- [ ] Processo de aprovação e auditoria de *rollback*\n:::\n\n**Artefactos & evidências.** Procedimentos (1 por tipo), logs de testes trimestrais, evidência de reversão de BD, configuração IaC com reversão, auditoria de *rollbacks* executados.\n\n**Proporcionalidade L1–L3.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Manual documentado | Automatizado (binário + config) | Automatizado todos os tipos + testado |\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|------|---------|-------------|-----|\n| Incidente | Falha em produção | DevOps/SRE | ≤ 15 min |\n\n**Ligações úteis.** [Monitorização & Operações](/sbd-toe/sbd-manual/monitorizacao-operacoes/intro)\n\n---", "title": "US-12 - *Rollback* estruturado por tipo (binário, configuração, BD, infra)", "traceability": {"line_end": 569, "line_start": 524, "source_path": "010-sbd-manual/11-deploy-seguro/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-12-rollback-estruturado-por-tipo-binario-configuracao-bd-infra"}, "vector_text": "US-12 - *Rollback* estruturado por tipo (binário, configuração, BD, infra)\n\n### US-12 - *Rollback* estruturado por tipo (binário, configuração, BD, infra)\n\nNem todos os *rollbacks* são iguais. Sem plano específico por tipo, a reversão tende a ser manual, lenta e arriscada.\n\n**Contexto.** *Rollbacks* não planeados amplificam o tempo de recuperação e o risco de inconsistência.\n\n:::userstory\n**História.** \nComo **DevOps/SRE**, quero **documentar e testar *rollback* para cada tipo de alteração (binário, configuração, BD, infraestrutura)**, para **reverter incidentes rapidamente com confiança**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um incidente em produção \n **Quando** aciono *rollback* \n **Então** existe um procedimento aplicável ao tipo de alteração e fica evidência registada (quem, quando, versão alvo)\n\n- **Dado** uma alteração de BD ou infraestrutura \n **Quando** ocorre reversão \n **Então** existe controlo de consistência (migrações reversíveis/snapshots; estado IaC conhecido) e validação pós-*rollback*\n\n**Checklist.** \n- [ ] Plano de *rollback* por tipo documentado e revisto \n- [ ] *Rollback* binário: *tag* Git anterior identificada + testada \n- [ ] *Rollback* de configuração: *feature flags* / variáveis revertíveis \n- [ ] *Rollback* de BD: migração reversa ou *snapshot* testado \n- [ ] *Rollback* de infra: Terraform/Helm com estado conhecido e procedimento seguro \n- [ ] Testes de *rollback* executados trimestralmente (evidência) \n- [ ] SLA por tipo definido e comunicado \n- [ ] Processo de aprovação e auditoria de *rollback*\n:::\n\n**Artefactos & evidências.** Procedimentos (1 por tipo), logs de testes trimestrais, evidência de reversão de BD, configuração IaC com reversão, auditoria de *rollbacks* executados.\n\n**Proporcionalidade L1–L3.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Manual documentado | Automatizado (binário + config) | Automatizado todos os tipos + testado |\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|------|---------|-------------|-----|\n| Incidente | Falha em produção | DevOps/SRE | ≤ 15 min |\n\n**Ligações úteis.** [Monitorização & Operações](/sbd-toe/sbd-manual/monitorizacao-operacoes/intro)\n\n---"}
|
|
2929
|
-
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-13-validacao-humana-obrigatoria-apos-deploy-automatizado", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-13"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-13-validacao-humana-obrigatoria-apos-deploy-automatizado", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📖 User Stories Reutilizáveis", "US-13 - Validação humana obrigatória após deploy automatizado"], "size_estimate": {"approx_tokens":
|
|
2930
|
-
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-14-controlo-e-validacao-de-drift-operacional", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-14"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-14-controlo-e-validacao-de-drift-operacional", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📖 User Stories Reutilizáveis", "US-14 - Controlo e validação de drift operacional"], "size_estimate": {"approx_tokens":
|
|
2931
|
-
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-15-reprodutibilidade-de-incidentes-em-runtime", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-15"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-15-reprodutibilidade-de-incidentes-em-runtime", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📖 User Stories Reutilizáveis", "US-15 - Reprodutibilidade de incidentes em runtime"], "size_estimate": {"approx_tokens":
|
|
2932
|
-
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados", "chunk_kind": "table_section", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "table_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados", "relation_hints": [], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📦 Artefactos esperados"], "size_estimate": {"approx_tokens": 265, "chars": 1057}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## 📦 Artefactos esperados\n\nCada prática deve deixar um rasto verificável. \nEstes artefactos constituem a evidência objetiva necessária para auditorias e conformidade:\n\n| Artefacto | Evidência |\n|-----------|-----------|\n| Artefacto assinado + SBOM | Proveniência validada |\n| Relatórios de *staging* | Testes funcionais + DAST + segregação de dados |\n| Configuração de *gates* | Pipeline versionado |\n| Logs de *rollback* | Evidência de reversão |\n| Rastreabilidade *end-to-end* | *Commit* → *release* → *deploy* |\n| Monitorização pós-deploy | *Dashboards* + alertas |\n| Configuração de *feature flags* | Versionada (YAML/JSON) + logs de auditoria |\n| Logs de *secret scanning* | Bloqueios em CI + artefactos limpos |\n| `CHANGELOG.md` e *tags* Git | Versionamento + metadata de *release* |\n| Configuração de *rollout* progressivo | Configuração + métricas por etapa |\n| Validações técnicas pré-deploy | Relatórios + decisões de *findings* + evidência |\n| Procedimentos de *rollback* por tipo | Documentos + testes trimestrais |\n\n---", "title": "📦 Artefactos esperados", "traceability": {"line_end":
|
|
2933
|
-
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-16-separacao-entre-acao-automatica-e-autorizacao-irreversivel", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-16"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-16-separacao-entre-acao-automatica-e-autorizacao-irreversivel", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📦 Artefactos esperados", "US-16 - Separação entre ação automática e autorização irreversível"], "size_estimate": {"approx_tokens":
|
|
2934
|
-
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-17-evidencia-operacional-auditavel", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-17"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-17-evidencia-operacional-auditavel", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📦 Artefactos esperados", "US-17 - Evidência operacional auditável"], "size_estimate": {"approx_tokens":
|
|
2935
|
-
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-18-release-gates-especificos-para-sistemas-com-agentes-ai-us-18", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": ["operations-monitoring", "secure-deploy"], "phase": ["deploy"], "risk_level": ["L2", "L3"]}, "mentioned_entities": {"Requirement": ["DPL-010", "DPL-011", "OPS-011", "OPS-013", "OPS-014"], "UserStory": ["US-13", "US-18", "US-19"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-18-release-gates-especificos-para-sistemas-com-agentes-ai-us-18", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📦 Artefactos esperados", "US-18 - Release gates específicos para sistemas com agentes AI {#us-18}"], "size_estimate": {"approx_tokens": 1454, "chars": 5816}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-18 - Release gates específicos para sistemas com agentes AI {#us-18}\n\n**Contexto.**\nQuando o sistema inclui **agentes AI** ou um **modelo AI como dependência *load-bearing***, o *release* deixa de ser apenas \"novo binário aplicacional → produção\". Há três artefactos novos no caminho crítico que podem mudar comportamento sem o binário aplicacional mudar: **versão do modelo**, ***skill files* / *system prompts*** que dirigem o agente, e ***eval suite*** que sustenta a classificação de autonomia A0–A4. O *release* tem de tratar estes três como dimensões próprias, com *gates*, *rollback* independente e estratégia de *canary*.\n\n:::userstory\n**História.**\nComo **DevOps / SRE** e **AppSec**, quero que o *release* de sistemas com agentes AI tenha *gates* específicos — *eval suite* como gate; *rollback* de modelo independente do *rollback* aplicacional; *canary release* de versão de modelo — para garantir que mudanças que afectam o comportamento agentic são tão controláveis e reversíveis quanto mudanças de código.\n\n**Critérios de aceitação (BDD).**\n- **Dado** uma promoção para produção que altera modelo, *skill files* ou *system prompts*\n **Quando** o pipeline de *release* corre\n **Então** a *eval suite* (Cap. 10 §C5) corre como *gate* obrigatório; *fail* bloqueia a promoção\n- **Dado** que uma versão de modelo em produção apresenta degradação ([`OPS-011`](/sbd-toe/sbd-manual/monitorizacao-operacoes/addon/catalogo-requisitos-operacoes) *drift*, [`OPS-014`](/sbd-toe/sbd-manual/monitorizacao-operacoes/addon/catalogo-requisitos-operacoes#ops-014) *off-policy actions* aumentaram, [`OPS-013`](/sbd-toe/sbd-manual/monitorizacao-operacoes/addon/catalogo-requisitos-operacoes#ops-013) *budget overrun*)\n **Quando** se decide reverter\n **Então** existe procedimento de *rollback* da versão do modelo **sem** reverter o binário aplicacional (e vice-versa)\n- **Dado** uma mudança de versão maior do modelo (provider muda, novo *fine-tune*, ou novo *system prompt* com impacto material)\n **Quando** se promove para produção\n **Então** a estratégia é *canary* — fracção controlada de tráfego direccionada à nova versão durante janela observável, com critérios objectivos de promoção ou rollback\n- **Dado** um *mandate* de agente (Policy 38) com `autonomy_level` declarado\n **Quando** a *eval suite* falha ou o `m_recall` da cobertura desce abaixo do limiar\n **Então** o agente desce automaticamente para o nível inferior (e.g. A3 → A2) até resolução; não opera no nível pedido\n\n**Critérios de aceitação (DoD).**\n- [ ] *Eval suite* registada como *gate* obrigatório no pipeline (cross-link Cap. 07 [US-19](/sbd-toe/sbd-manual/cicd-seguro/aplicacao-lifecycle))\n- [ ] `eval_run_id` ligado ao *release* e arquivado como evidência\n- [ ] Procedimento de *rollback* de modelo independente documentado (revogar *deployment* do modelo no *artifact registry* / *model registry*, sem tocar no binário aplicacional)\n- [ ] Procedimento de *rollback* de *system prompt* / *skill file* independente (revert do *commit* dos *skill files* não obriga a redeploy aplicacional se o *runtime* lê dinamicamente do *registry*)\n- [ ] Estratégia *canary* configurada para promoções de modelo: fracção inicial (tipicamente 5–10%), critérios de promoção (taxa de erro, *off-policy events*, latência, *user satisfaction* quando disponível), critérios de *rollback* automático\n- [ ] *Gate* automático que desce o `autonomy_level` quando a *eval suite* não confirma o nível pretendido (cross-link [Policy 38](/sbd-toe/assets/policies/policy-mandates-agentes) §5.4)\n- [ ] *Release notes* incluem versão de modelo, versão de *skill files*, *eval suite* version, `mandate_ref`\n\n:::\n\n**🧾 Artefactos & evidências.**\n- *Pipeline manifest* com *eval gate* configurado\n- `eval_run_id` por *release* arquivado e correlacionado com `mandate_ref`\n- *Runbook* de *model rollback* (separado do *rollback* aplicacional)\n- *Runbook* de *prompt/skill rollback*\n- *Canary release plan* por mudança de versão maior de modelo, com critérios objectivos\n- *Logs* de *autonomy demotion* automático quando *eval* falha\n- *Release notes* alargadas com versões agentic\n\n**⚖️ Proporcionalidade.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Recomendado | *Eval gate* simples; *rollback* de modelo pode partilhar pipeline com aplicação |\n| L2 | Sim para A1+ | *Eval gate* completo; *rollback* de modelo independente documentado; *canary* recomendado |\n| L3 | Sim para A1+ | *Eval gate* completo + *canary* obrigatório em mudança de versão maior + auditoria do `eval_run_id` |\n\n**🔗 Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Pré-promoção | *Eval gate* falha | DevOps + AppSec | Bloqueio imediato |\n| Promoção | Mudança de versão maior de modelo / prompt | DevOps + AppSec + *owner* do agente (Policy 38) | Janela *canary* declarada |\n| Degradação em produção | `OPS-011/013/014` dispara | Ops + AppSec | *Rollback* conforme nível de severidade |\n| Auditoria | `review_cadence` do *mandate* | AppSec | Conforme cadência |\n\n**Ligações úteis.**\n- 🔗 [Cap. 07 US-19 — Agentes na pipeline](/sbd-toe/sbd-manual/cicd-seguro/aplicacao-lifecycle)\n- 🔗 [Cap. 10 §C5 — Eval suites](/sbd-toe/sbd-manual/testes-seguranca/addon/ia-nos-testes#c5-eval-suites)\n- 🔗 [Cap. 12 — `OPS-011..014`](/sbd-toe/sbd-manual/monitorizacao-operacoes/addon/catalogo-requisitos-operacoes)\n- 🔗 [Cap. 12 US-13 — Telemetria agentic](/sbd-toe/sbd-manual/monitorizacao-operacoes/aplicacao-lifecycle)\n- 🔗 [Policy 38 §5.4 — Activação do mandate](/sbd-toe/assets/policies/policy-mandates-agentes)\n- 🔗 [Policy 39 §5 — Version pinning](/sbd-toe/assets/policies/policy-ai-bom-supply-chain)\n- 🔗 Grounding canónico: [`DPL-010` / `DPL-011`](./addon/catalogo-requisitos-deploy)\n\n---", "title": "US-18 - Release gates específicos para sistemas com agentes AI {#us-18}", "traceability": {"line_end": 794, "line_start": 726, "source_path": "010-sbd-manual/11-deploy-seguro/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-18-release-gates-especificos-para-sistemas-com-agentes-ai-us-18"}, "vector_text": "US-18 - Release gates específicos para sistemas com agentes AI {#us-18}\n\n### US-18 - Release gates específicos para sistemas com agentes AI {#us-18}\n\n**Contexto.**\nQuando o sistema inclui **agentes AI** ou um **modelo AI como dependência *load-bearing***, o *release* deixa de ser apenas \"novo binário aplicacional → produção\". Há três artefactos novos no caminho crítico que podem mudar comportamento sem o binário aplicacional mudar: **versão do modelo**, ***skill files* / *system prompts*** que dirigem o agente, e ***eval suite*** que sustenta a classificação de autonomia A0–A4. O *release* tem de tratar estes três como dimensões próprias, com *gates*, *rollback* independente e estratégia de *canary*.\n\n:::userstory\n**História.**\nComo **DevOps / SRE** e **AppSec**, quero que o *release* de sistemas com agentes AI tenha *gates* específicos — *eval suite* como gate; *rollback* de modelo independente do *rollback* aplicacional; *canary release* de versão de modelo — para garantir que mudanças que afectam o comportamento agentic são tão controláveis e reversíveis quanto mudanças de código.\n\n**Critérios de aceitação (BDD).**\n- **Dado** uma promoção para produção que altera modelo, *skill files* ou *system prompts*\n **Quando** o pipeline de *release* corre\n **Então** a *eval suite* (Cap. 10 §C5) corre como *gate* obrigatório; *fail* bloqueia a promoção\n- **Dado** que uma versão de modelo em produção apresenta degradação ([`OPS-011`](/sbd-toe/sbd-manual/monitorizacao-operacoes/addon/catalogo-requisitos-operacoes) *drift*, [`OPS-014`](/sbd-toe/sbd-manual/monitorizacao-operacoes/addon/catalogo-requisitos-operacoes#ops-014) *off-policy actions* aumentaram, [`OPS-013`](/sbd-toe/sbd-manual/monitorizacao-operacoes/addon/catalogo-requisitos-operacoes#ops-013) *budget overrun*)\n **Quando** se decide reverter\n **Então** existe procedimento de *rollback* da versão do modelo **sem** reverter o binário aplicacional (e vice-versa)\n- **Dado** uma mudança de versão maior do modelo (provider muda, novo *fine-tune*, ou novo *system prompt* com impacto material)\n **Quando** se promove para produção\n **Então** a estratégia é *canary* — fracção controlada de tráfego direccionada à nova versão durante janela observável, com critérios objectivos de promoção ou rollback\n- **Dado** um *mandate* de agente (Policy 38) com `autonomy_level` declarado\n **Quando** a *eval suite* falha ou o `m_recall` da cobertura desce abaixo do limiar\n **Então** o agente desce automaticamente para o nível inferior (e.g. A3 → A2) até resolução; não opera no nível pedido\n\n**Critérios de aceitação (DoD).**\n- [ ] *Eval suite* registada como *gate* obrigatório no pipeline (cross-link Cap. 07 [US-19](/sbd-toe/sbd-manual/cicd-seguro/aplicacao-lifecycle))\n- [ ] `eval_run_id` ligado ao *release* e arquivado como evidência\n- [ ] Procedimento de *rollback* de modelo independente documentado (revogar *deployment* do modelo no *artifact registry* / *model registry*, sem tocar no binário aplicacional)\n- [ ] Procedimento de *rollback* de *system prompt* / *skill file* independente (revert do *commit* dos *skill files* não obriga a redeploy aplicacional se o *runtime* lê dinamicamente do *registry*)\n- [ ] Estratégia *canary* configurada para promoções de modelo: fracção inicial (tipicamente 5–10%), critérios de promoção (taxa de erro, *off-policy events*, latência, *user satisfaction* quando disponível), critérios de *rollback* automático\n- [ ] *Gate* automático que desce o `autonomy_level` quando a *eval suite* não confirma o nível pretendido (cross-link [Policy 38](/sbd-toe/assets/policies/policy-mandates-agentes) §5.4)\n- [ ] *Release notes* incluem versão de modelo, versão de *skill files*, *eval suite* version, `mandate_ref`\n\n:::\n\n**🧾 Artefactos & evidências.**\n- *Pipeline manifest* com *eval gate* configurado\n- `eval_run_id` por *release* arquivado e correlacionado com `mandate_ref`\n- *Runbook* de *model rollback* (separado do *rollback* aplicacional)\n- *Runbook* de *prompt/skill rollback*\n- *Canary release plan* por mudança de versão maior de modelo, com critérios objectivos\n- *Logs* de *autonomy demotion* automático quando *eval* falha\n- *Release notes* alargadas com versões agentic\n\n**⚖️ Proporcionalidade.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Recomendado | *Eval gate* simples; *rollback* de modelo pode partilhar pipeline com aplicação |\n| L2 | Sim para A1+ | *Eval gate* completo; *rollback* de modelo independente documentado; *canary* recomendado |\n| L3 | Sim para A1+ | *Eval gate* completo + *canary* obrigatório em mudança de versão maior + auditoria do `eval_run_id` |\n\n**🔗 Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Pré-promoção | *Eval gate* falha | DevOps + AppSec | Bloqueio imediato |\n| Promoção | Mudança de versão maior de modelo / prompt | DevOps + AppSec + *owner* do agente (Policy 38) | Janela *canary* declarada |\n| Degradação em produção | `OPS-011/013/014` dispara | Ops + AppSec | *Rollback* conforme nível de severidade |\n| Auditoria | `review_cadence` do *mandate* | AppSec | Conforme cadência |\n\n**Ligações úteis.**\n- 🔗 [Cap. 07 US-19 — Agentes na pipeline](/sbd-toe/sbd-manual/cicd-seguro/aplicacao-lifecycle)\n- 🔗 [Cap. 10 §C5 — Eval suites](/sbd-toe/sbd-manual/testes-seguranca/addon/ia-nos-testes#c5-eval-suites)\n- 🔗 [Cap. 12 — `OPS-011..014`](/sbd-toe/sbd-manual/monitorizacao-operacoes/addon/catalogo-requisitos-operacoes)\n- 🔗 [Cap. 12 US-13 — Telemetria agentic](/sbd-toe/sbd-manual/monitorizacao-operacoes/aplicacao-lifecycle)\n- 🔗 [Policy 38 §5.4 — Activação do mandate](/sbd-toe/assets/policies/policy-mandates-agentes)\n- 🔗 [Policy 39 §5 — Version pinning](/sbd-toe/assets/policies/policy-ai-bom-supply-chain)\n- 🔗 Grounding canónico: [`DPL-010` / `DPL-011`](./addon/catalogo-requisitos-deploy)\n\n---"}
|
|
2936
|
-
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-19-credenciais-de-deploy-isoladas-por-aplicacao-e-efemeras", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": ["secure-deploy"], "phase": ["deploy"], "risk_level": ["L1", "L2", "L3"]}, "mentioned_entities": {"Requirement": ["DPL-006"], "UserStory": ["US-08", "US-19"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-19-credenciais-de-deploy-isoladas-por-aplicacao-e-efemeras", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📦 Artefactos esperados", "US-19 - Credenciais de *deploy* isoladas por aplicação e efémeras"], "size_estimate": {"approx_tokens": 719, "chars": 2875}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-19 - Credenciais de *deploy* isoladas por aplicação e efémeras\n\nUma credencial de *deploy* partilhada transforma o compromisso de um pipeline no compromisso de todos os que ela alcança. \n\n**Contexto.** As credenciais usadas no momento do *deploy* combinam acesso privilegiado a ambientes de produção com automação não-supervisionada. Quando são permanentes ou partilhadas entre aplicações, um único *token* exfiltrado dá movimento lateral a todo o portfólio e torna impossível atribuir uso indevido a uma aplicação concreta. A US-08 cobre segredos *aplicacionais* injetados em *runtime*; esta US trata as credenciais *do pipeline de deploy* — âmbito mínimo, vida curta e isolamento por aplicação (`DPL-006`). \n\n:::userstory\n**História.** \nComo **DevOps/SRE**, quero **que cada aplicação use credenciais de *deploy* próprias, de âmbito mínimo e curta duração, nunca partilhadas entre aplicações**, para **conter o raio de impacto de uma credencial comprometida e tornar o uso atribuível e auditável**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** um pipeline de *deploy* de uma aplicação \n **Quando** o pipeline se autentica para promover a produção \n **Então** usa uma identidade efémera por execução (OIDC / *workload identity*), sem chaves persistentes \n- **Dado** o conjunto de credenciais de *deploy* do portfólio \n **Quando** se audita o seu âmbito \n **Então** nenhuma credencial de *deploy* é partilhada entre aplicações e cada uma tem apenas as permissões necessárias ao seu alvo \n- **Dado** uma promoção a produção \n **Quando** a credencial é usada \n **Então** o uso fica registado (identidade, aplicação, timestamp, ambiente) e correlacionável com o *deploy* \n\n**Checklist.** \n- [ ] OIDC / *workload identity* configurado (sem chaves de longa duração no *deploy*) \n- [ ] Credenciais de *deploy* distintas por aplicação (sem partilha entre apps) \n- [ ] Âmbito mínimo por credencial (permissões limitadas ao alvo) \n- [ ] Logs de uso de credenciais centralizados e correlacionáveis com o *deploy* \n\n:::\n\n**Artefactos & evidências.** Configuração de *workload identity*/OIDC por pipeline, inventário de credenciais de *deploy* por aplicação, logs de uso de credenciais. \n\n**Proporcionalidade L1–L3.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Âmbito mínimo documentado; sem partilha entre apps | OIDC/*workload identity* (tokens efémeros); isolamento por app | OIDC obrigatório + auditoria periódica de âmbito e logs de uso |\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|------|---------|-------------|-----|\n| Build/Deploy | Autenticação do pipeline | DevOps/SRE | Cada deploy |\n\n**Ligações úteis.** [Catálogo DPL-006](/sbd-toe/sbd-manual/deploy-seguro/addon/catalogo-requisitos-deploy) · [CI/CD Seguro](/sbd-toe/sbd-manual/cicd-seguro/intro)\n\n---", "title": "US-19 - Credenciais de *deploy* isoladas por aplicação e efémeras", "traceability": {"line_end":
|
|
2937
|
-
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-20-feature-flags-avaliadas-no-backend-como-fronteira-de-confianca", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-07", "US-20"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-20-feature-flags-avaliadas-no-backend-como-fronteira-de-confianca", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📦 Artefactos esperados", "US-20 - *Feature flags* avaliadas no *backend* como fronteira de confiança"], "size_estimate": {"approx_tokens": 715, "chars": 2859}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-20 - *Feature flags* avaliadas no *backend* como fronteira de confiança\n\nUm *toggle* avaliado no cliente não controla nada: protege apenas o que o utilizador escolhe não contornar. \n\n**Contexto.** *Feature flags* que decidem exposição de funcionalidades sensíveis têm de ser avaliadas no *backend*. A avaliação *client-side* é manipulável pela UI e permite *bypass* trivial; e um *toggle* nunca substitui controlo de acesso. A US-07 cobre o ciclo de vida da *flag* (metadata, *owner*, expiração, versionamento como código); esta US trata a propriedade de segurança da avaliação — onde a decisão é tomada e como o *fallback* é validado. \n\n:::userstory\n**História.** \nComo **Dev/AppSec**, quero **que toggles que controlam lógica sensível sejam avaliados no *backend*, nunca apenas no *frontend*, e nunca como substituto de controlo de acesso**, para **impedir *bypass* via manipulação da UI e garantir que a fronteira de confiança é o servidor**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** um *toggle* que controla uma funcionalidade ou fluxo sensível \n **Quando** a funcionalidade é solicitada \n **Então** a decisão de ativação é avaliada e imposta no *backend* (a UI não é a fronteira de decisão) \n- **Dado** um *toggle* manipulado no cliente (UI/parâmetro) \n **Quando** o pedido chega ao servidor \n **Então** o *backend* impõe o estado correto e o *bypass* não tem efeito \n- **Dado** um *toggle* crítico \n **Quando** está ativo e quando está desligado \n **Então** ambos os caminhos lógicos (com e sem *toggle*) são testáveis e têm *fallback* definido \n\n**Checklist.** \n- [ ] *Toggles* de lógica sensível avaliados no *backend* (não apenas *frontend*) \n- [ ] *Toggle* não usado como substituto de controlo de acesso (autorização independente) \n- [ ] Caminhos com e sem *toggle* testáveis, com *fallback* definido \n- [ ] Avaliação/alteração de *toggle* registada em logs (não silenciosa) \n\n:::\n\n**Artefactos & evidências.** Evidência de avaliação *server-side* (código/configuração), testes dos caminhos com e sem *toggle*, logs de avaliação de *toggle*. \n\n**Proporcionalidade L1–L3.** \n| L1 | L2 | L3 |\n|----|----|----|\n| *Backend* para *toggles* sensíveis; *fallback* documentado | *Backend* para todos os *toggles* de lógica; ambos os caminhos testados | *Backend* + autorização independente + logs auditáveis de avaliação |\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|------|---------|-------------|-----|\n| Desenvolvimento/Deploy | Introdução ou alteração de *toggle* sensível | Dev + AppSec | Cada PR de *toggle* |\n\n**Ligações úteis.** [Feature Flags e Toggles](/sbd-toe/sbd-manual/deploy-seguro/addon/03-feature-flags-e-toggle) · [Monitorização & Operações](/sbd-toe/sbd-manual/monitorizacao-operacoes/intro)\n\n---", "title": "US-20 - *Feature flags* avaliadas no *backend* como fronteira de confiança", "traceability": {"line_end":
|
|
2938
|
-
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--matriz-de-proporcionalidade-l1l3", "chunk_kind": "table_section", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "table_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--matriz-de-proporcionalidade-l1l3", "relation_hints": [], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "⚖️ Matriz de proporcionalidade L1–L3"], "size_estimate": {"approx_tokens": 167, "chars": 666}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## ⚖️ Matriz de proporcionalidade L1–L3\n\nNem todas as aplicações exigem o mesmo nível de controlo. \nA proporcionalidade permite adaptar rigor sem comprometer segurança:\n\n| Prática | L1 | L2 | L3 |\n|---------|----|----|----|\n| Deploy de artefactos assinados | Recomendado | Obrigatório | Obrigatório + rejeição automática |\n| Validação em *staging* | Opcional | Recomendado | Obrigatório |\n| *Gates* de aprovação | Aviso | Bloqueio High/Critical | Bloqueio Medium+ |\n| *Rollback* | Manual | Automatizado | Automatizado + testado |\n| Rastreabilidade | Básica | Completa | Completa + auditoria |\n| Monitorização | Básica | Crítica", "title": "⚖️ Matriz de proporcionalidade L1–L3", "traceability": {"line_end":
|
|
2929
|
+
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-13-validacao-humana-obrigatoria-apos-deploy-automatizado", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-13"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-13-validacao-humana-obrigatoria-apos-deploy-automatizado", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📖 User Stories Reutilizáveis", "US-13 - Validação humana obrigatória após deploy automatizado"], "size_estimate": {"approx_tokens": 322, "chars": 1287}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-13 - Validação humana obrigatória após deploy automatizado\n\nUm deploy automático bem-sucedido não é sinónimo de operação segura.\nEsta US garante que qualquer promoção automática para produção é validada por um responsável humano.\n\n:::userstory\n**História.** \nComo **Ops/AppSec**, quero **validar explicitamente o estado de segurança após deploy automático**, para **assegurar que não existem impactos inesperados antes de considerar a release concluída**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** que um deploy automático para produção é concluído \n **Quando** o sistema entra em estado operacional \n **Então** existe validação humana documentada antes de fechar a release\n\n- **Dado** que métricas ou alertas indicam comportamento anómalo \n **Quando** a validação ocorre \n **Então** o deploy é marcado como pendente ou revertido até análise concluída\n:::\n\n**Artefactos & evidências.** Registo de validação pós-deploy, métricas observadas, decisão final.\n\n**Proporcionalidade.** \nL1: validação amostral \nL2: validação obrigatória \nL3: validação + aprovação dupla\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Produção | Pós-deploy | Ops/AppSec | `<`24h |\n\n---", "title": "US-13 - Validação humana obrigatória após deploy automatizado", "traceability": {"line_end": 602, "line_start": 570, "source_path": "010-sbd-manual/11-deploy-seguro/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-13-validacao-humana-obrigatoria-apos-deploy-automatizado"}, "vector_text": "US-13 - Validação humana obrigatória após deploy automatizado\n\n### US-13 - Validação humana obrigatória após deploy automatizado\n\nUm deploy automático bem-sucedido não é sinónimo de operação segura.\nEsta US garante que qualquer promoção automática para produção é validada por um responsável humano.\n\n:::userstory\n**História.** \nComo **Ops/AppSec**, quero **validar explicitamente o estado de segurança após deploy automático**, para **assegurar que não existem impactos inesperados antes de considerar a release concluída**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** que um deploy automático para produção é concluído \n **Quando** o sistema entra em estado operacional \n **Então** existe validação humana documentada antes de fechar a release\n\n- **Dado** que métricas ou alertas indicam comportamento anómalo \n **Quando** a validação ocorre \n **Então** o deploy é marcado como pendente ou revertido até análise concluída\n:::\n\n**Artefactos & evidências.** Registo de validação pós-deploy, métricas observadas, decisão final.\n\n**Proporcionalidade.** \nL1: validação amostral \nL2: validação obrigatória \nL3: validação + aprovação dupla\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Produção | Pós-deploy | Ops/AppSec | `<`24h |\n\n---"}
|
|
2930
|
+
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-14-controlo-e-validacao-de-drift-operacional", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-14"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-14-controlo-e-validacao-de-drift-operacional", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📖 User Stories Reutilizáveis", "US-14 - Controlo e validação de drift operacional"], "size_estimate": {"approx_tokens": 227, "chars": 906}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-14 - Controlo e validação de drift operacional\n\nAutomação contínua introduz risco de drift silencioso entre estado desejado e real.\n\n:::userstory\n**História.** \nComo **Ops**, quero **detetar e validar drift operacional**, para **garantir que alterações automáticas ou manuais não introduzem desvios inseguros**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um estado desejado definido \n **Quando** ocorre drift em produção \n **Então** o desvio é registado, analisado e validado antes de correção automática\n:::\n\n**Artefactos & evidências.** Relatórios de drift, decisão humana, histórico de correções.\n\n**Proporcionalidade.** \nL1: alerta \nL2: validação obrigatória \nL3: bloqueio até validação\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Operação contínua | Deteção de drift | Ops | `<48h` |\n\n---", "title": "US-14 - Controlo e validação de drift operacional", "traceability": {"line_end": 630, "line_start": 603, "source_path": "010-sbd-manual/11-deploy-seguro/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-14-controlo-e-validacao-de-drift-operacional"}, "vector_text": "US-14 - Controlo e validação de drift operacional\n\n### US-14 - Controlo e validação de drift operacional\n\nAutomação contínua introduz risco de drift silencioso entre estado desejado e real.\n\n:::userstory\n**História.** \nComo **Ops**, quero **detetar e validar drift operacional**, para **garantir que alterações automáticas ou manuais não introduzem desvios inseguros**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um estado desejado definido \n **Quando** ocorre drift em produção \n **Então** o desvio é registado, analisado e validado antes de correção automática\n:::\n\n**Artefactos & evidências.** Relatórios de drift, decisão humana, histórico de correções.\n\n**Proporcionalidade.** \nL1: alerta \nL2: validação obrigatória \nL3: bloqueio até validação\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Operação contínua | Deteção de drift | Ops | `<48h` |\n\n---"}
|
|
2931
|
+
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-15-reprodutibilidade-de-incidentes-em-runtime", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-15"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-15-reprodutibilidade-de-incidentes-em-runtime", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📖 User Stories Reutilizáveis", "US-15 - Reprodutibilidade de incidentes em runtime"], "size_estimate": {"approx_tokens": 224, "chars": 894}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-15 - Reprodutibilidade de incidentes em runtime\n\nSem reprodutibilidade, não existe auditoria nem melhoria.\n\n:::userstory\n**História.** \nComo **Ops/AppSec**, quero **garantir que incidentes em produção são reprodutíveis**, para **validar causas raiz e eficácia das correções**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um incidente operacional \n **Quando** é analisado \n **Então** existe contexto suficiente para reproduzir o comportamento observado\n:::\n\n**Artefactos & evidências.** Logs versionados, snapshots de configuração, relatório de RCA.\n\n**Proporcionalidade.** \nL1: reprodutibilidade básica \nL2: reprodutibilidade documentada \nL3: reprodutibilidade completa e auditável\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Produção | Incidente | Ops/AppSec | SLA definido |\n\n---", "title": "US-15 - Reprodutibilidade de incidentes em runtime", "traceability": {"line_end": 657, "line_start": 631, "source_path": "010-sbd-manual/11-deploy-seguro/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--user-stories-reutilizaveis--us-15-reprodutibilidade-de-incidentes-em-runtime"}, "vector_text": "US-15 - Reprodutibilidade de incidentes em runtime\n\n### US-15 - Reprodutibilidade de incidentes em runtime\n\nSem reprodutibilidade, não existe auditoria nem melhoria.\n\n:::userstory\n**História.** \nComo **Ops/AppSec**, quero **garantir que incidentes em produção são reprodutíveis**, para **validar causas raiz e eficácia das correções**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um incidente operacional \n **Quando** é analisado \n **Então** existe contexto suficiente para reproduzir o comportamento observado\n:::\n\n**Artefactos & evidências.** Logs versionados, snapshots de configuração, relatório de RCA.\n\n**Proporcionalidade.** \nL1: reprodutibilidade básica \nL2: reprodutibilidade documentada \nL3: reprodutibilidade completa e auditável\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Produção | Incidente | Ops/AppSec | SLA definido |\n\n---"}
|
|
2932
|
+
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados", "chunk_kind": "table_section", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "table_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados", "relation_hints": [], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📦 Artefactos esperados"], "size_estimate": {"approx_tokens": 265, "chars": 1057}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## 📦 Artefactos esperados\n\nCada prática deve deixar um rasto verificável. \nEstes artefactos constituem a evidência objetiva necessária para auditorias e conformidade:\n\n| Artefacto | Evidência |\n|-----------|-----------|\n| Artefacto assinado + SBOM | Proveniência validada |\n| Relatórios de *staging* | Testes funcionais + DAST + segregação de dados |\n| Configuração de *gates* | Pipeline versionado |\n| Logs de *rollback* | Evidência de reversão |\n| Rastreabilidade *end-to-end* | *Commit* → *release* → *deploy* |\n| Monitorização pós-deploy | *Dashboards* + alertas |\n| Configuração de *feature flags* | Versionada (YAML/JSON) + logs de auditoria |\n| Logs de *secret scanning* | Bloqueios em CI + artefactos limpos |\n| `CHANGELOG.md` e *tags* Git | Versionamento + metadata de *release* |\n| Configuração de *rollout* progressivo | Configuração + métricas por etapa |\n| Validações técnicas pré-deploy | Relatórios + decisões de *findings* + evidência |\n| Procedimentos de *rollback* por tipo | Documentos + testes trimestrais |\n\n---", "title": "📦 Artefactos esperados", "traceability": {"line_end": 679, "line_start": 658, "source_path": "010-sbd-manual/11-deploy-seguro/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados"}, "vector_text": "📦 Artefactos esperados\n\n## 📦 Artefactos esperados\n\nCada prática deve deixar um rasto verificável. \nEstes artefactos constituem a evidência objetiva necessária para auditorias e conformidade:\n\n| Artefacto | Evidência |\n|-----------|-----------|\n| Artefacto assinado + SBOM | Proveniência validada |\n| Relatórios de *staging* | Testes funcionais + DAST + segregação de dados |\n| Configuração de *gates* | Pipeline versionado |\n| Logs de *rollback* | Evidência de reversão |\n| Rastreabilidade *end-to-end* | *Commit* → *release* → *deploy* |\n| Monitorização pós-deploy | *Dashboards* + alertas |\n| Configuração de *feature flags* | Versionada (YAML/JSON) + logs de auditoria |\n| Logs de *secret scanning* | Bloqueios em CI + artefactos limpos |\n| `CHANGELOG.md` e *tags* Git | Versionamento + metadata de *release* |\n| Configuração de *rollout* progressivo | Configuração + métricas por etapa |\n| Validações técnicas pré-deploy | Relatórios + decisões de *findings* + evidência |\n| Procedimentos de *rollback* por tipo | Documentos + testes trimestrais |\n\n---"}
|
|
2933
|
+
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-16-separacao-entre-acao-automatica-e-autorizacao-irreversivel", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-16"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-16-separacao-entre-acao-automatica-e-autorizacao-irreversivel", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📦 Artefactos esperados", "US-16 - Separação entre ação automática e autorização irreversível"], "size_estimate": {"approx_tokens": 229, "chars": 913}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-16 - Separação entre ação automática e autorização irreversível\n\nFerramentas podem agir, mas não decidir impactos irreversíveis.\n\n:::userstory\n**História.** \nComo **Ops**, quero **separar execução automática de ações irreversíveis da autorização humana**, para **garantir controlo e responsabilidade explícita**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** que uma ação irreversível é proposta automaticamente \n **Quando** é executada \n **Então** existe autorização humana registada previamente\n:::\n\n**Artefactos & evidências.** Registo de autorização, logs de execução, identidade do decisor.\n\n**Proporcionalidade.** \nL1: registo simples \nL2: autorização formal \nL3: dupla aprovação\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Produção | Ação crítica | Ops | Antes da execução |\n\n---", "title": "US-16 - Separação entre ação automática e autorização irreversível", "traceability": {"line_end": 707, "line_start": 680, "source_path": "010-sbd-manual/11-deploy-seguro/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-16-separacao-entre-acao-automatica-e-autorizacao-irreversivel"}, "vector_text": "US-16 - Separação entre ação automática e autorização irreversível\n\n### US-16 - Separação entre ação automática e autorização irreversível\n\nFerramentas podem agir, mas não decidir impactos irreversíveis.\n\n:::userstory\n**História.** \nComo **Ops**, quero **separar execução automática de ações irreversíveis da autorização humana**, para **garantir controlo e responsabilidade explícita**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** que uma ação irreversível é proposta automaticamente \n **Quando** é executada \n **Então** existe autorização humana registada previamente\n:::\n\n**Artefactos & evidências.** Registo de autorização, logs de execução, identidade do decisor.\n\n**Proporcionalidade.** \nL1: registo simples \nL2: autorização formal \nL3: dupla aprovação\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Produção | Ação crítica | Ops | Antes da execução |\n\n---"}
|
|
2934
|
+
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-17-evidencia-operacional-auditavel", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-17"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-17-evidencia-operacional-auditavel", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📦 Artefactos esperados", "US-17 - Evidência operacional auditável"], "size_estimate": {"approx_tokens": 212, "chars": 846}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-17 - Evidência operacional auditável\n\nLogs e métricas só têm valor quando tratados como evidência.\n\n:::userstory\n**História.** \nComo **GRC/AppSec**, quero **tratar evidência operacional como artefacto auditável**, para **demonstrar controlo efetivo em operação**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um evento relevante (deploy, rollback, incidente) \n **Quando** ocorre \n **Então** a evidência é preservada, versionada e acessível para auditoria\n:::\n\n**Artefactos & evidências.** Logs imutáveis, retenção definida, trilhos de auditoria.\n\n**Proporcionalidade.** \nL1: retenção curta \nL2: retenção definida \nL3: retenção + revisão periódica\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Operação contínua | Evento | Ops/GRC | Imediato |\n\n---", "title": "US-17 - Evidência operacional auditável", "traceability": {"line_end": 735, "line_start": 708, "source_path": "010-sbd-manual/11-deploy-seguro/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-17-evidencia-operacional-auditavel"}, "vector_text": "US-17 - Evidência operacional auditável\n\n### US-17 - Evidência operacional auditável\n\nLogs e métricas só têm valor quando tratados como evidência.\n\n:::userstory\n**História.** \nComo **GRC/AppSec**, quero **tratar evidência operacional como artefacto auditável**, para **demonstrar controlo efetivo em operação**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um evento relevante (deploy, rollback, incidente) \n **Quando** ocorre \n **Então** a evidência é preservada, versionada e acessível para auditoria\n:::\n\n**Artefactos & evidências.** Logs imutáveis, retenção definida, trilhos de auditoria.\n\n**Proporcionalidade.** \nL1: retenção curta \nL2: retenção definida \nL3: retenção + revisão periódica\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Operação contínua | Evento | Ops/GRC | Imediato |\n\n---"}
|
|
2935
|
+
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-18-release-gates-especificos-para-sistemas-com-agentes-ai-us-18", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": ["operations-monitoring", "secure-deploy"], "phase": ["deploy"], "risk_level": ["L2", "L3"]}, "mentioned_entities": {"Requirement": ["DPL-010", "DPL-011", "OPS-011", "OPS-013", "OPS-014"], "UserStory": ["US-13", "US-18", "US-19"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-18-release-gates-especificos-para-sistemas-com-agentes-ai-us-18", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📦 Artefactos esperados", "US-18 - Release gates específicos para sistemas com agentes AI {#us-18}"], "size_estimate": {"approx_tokens": 1454, "chars": 5814}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-18 - Release gates específicos para sistemas com agentes AI {#us-18}\n\n**Contexto.**\nQuando o sistema inclui **agentes AI** ou um **modelo AI como dependência *load-bearing***, o *release* deixa de ser apenas \"novo binário aplicacional → produção\". Há três artefactos novos no caminho crítico que podem mudar comportamento sem o binário aplicacional mudar: **versão do modelo**, ***skill files* / *system prompts*** que dirigem o agente, e ***eval suite*** que sustenta a classificação de autonomia A0–A4. O *release* tem de tratar estes três como dimensões próprias, com *gates*, *rollback* independente e estratégia de *canary*.\n\n:::userstory\n**História.**\nComo **DevOps / SRE** e **AppSec**, quero que o *release* de sistemas com agentes AI tenha *gates* específicos — *eval suite* como gate; *rollback* de modelo independente do *rollback* aplicacional; *canary release* de versão de modelo — para garantir que mudanças que afectam o comportamento agentic são tão controláveis e reversíveis quanto mudanças de código.\n\n**Critérios de aceitação (BDD).**\n- **Dado** uma promoção para produção que altera modelo, *skill files* ou *system prompts*\n **Quando** o pipeline de *release* corre\n **Então** a *eval suite* (Cap. 10 §C5) corre como *gate* obrigatório; *fail* bloqueia a promoção\n- **Dado** que uma versão de modelo em produção apresenta degradação ([`OPS-011`](/sbd-toe/sbd-manual/monitorizacao-operacoes/addon/catalogo-requisitos-operacoes) *drift*, [`OPS-014`](/sbd-toe/sbd-manual/monitorizacao-operacoes/addon/catalogo-requisitos-operacoes#ops-014) *off-policy actions* aumentaram, [`OPS-013`](/sbd-toe/sbd-manual/monitorizacao-operacoes/addon/catalogo-requisitos-operacoes#ops-013) *budget overrun*)\n **Quando** se decide reverter\n **Então** existe procedimento de *rollback* da versão do modelo **sem** reverter o binário aplicacional (e vice-versa)\n- **Dado** uma mudança de versão maior do modelo (provider muda, novo *fine-tune*, ou novo *system prompt* com impacto material)\n **Quando** se promove para produção\n **Então** a estratégia é *canary* — fracção controlada de tráfego direccionada à nova versão durante janela observável, com critérios objectivos de promoção ou rollback\n- **Dado** um *mandate* de agente (Policy 38) com `autonomy_level` declarado\n **Quando** a *eval suite* falha ou o `m_recall` da cobertura desce abaixo do limiar\n **Então** o agente desce automaticamente para o nível inferior (e.g. A3 → A2) até resolução; não opera no nível pedido\n\n**Critérios de aceitação (DoD).**\n- [ ] *Eval suite* registada como *gate* obrigatório no pipeline (cross-link Cap. 07 [US-19](/sbd-toe/sbd-manual/cicd-seguro/aplicacao-lifecycle))\n- [ ] `eval_run_id` ligado ao *release* e arquivado como evidência\n- [ ] Procedimento de *rollback* de modelo independente documentado (revogar *deployment* do modelo no *artifact registry* / *model registry*, sem tocar no binário aplicacional)\n- [ ] Procedimento de *rollback* de *system prompt* / *skill file* independente (revert do *commit* dos *skill files* não obriga a redeploy aplicacional se o *runtime* lê dinamicamente do *registry*)\n- [ ] Estratégia *canary* configurada para promoções de modelo: fracção inicial (tipicamente 5–10%), critérios de promoção (taxa de erro, *off-policy events*, latência, *user satisfaction* quando disponível), critérios de *rollback* automático\n- [ ] *Gate* automático que desce o `autonomy_level` quando a *eval suite* não confirma o nível pretendido (cross-link [Policy 38](/sbd-toe/assets/policies/policy-mandates-agentes) §5.4)\n- [ ] *Release notes* incluem versão de modelo, versão de *skill files*, *eval suite* version, `mandate_ref`\n\n:::\n\n**🧾 Artefactos & evidências.**\n- *Pipeline manifest* com *eval gate* configurado\n- `eval_run_id` por *release* arquivado e correlacionado com `mandate_ref`\n- *Runbook* de *model rollback* (separado do *rollback* aplicacional)\n- *Runbook* de *prompt/skill rollback*\n- *Canary release plan* por mudança de versão maior de modelo, com critérios objectivos\n- *Logs* de *autonomy demotion* automático quando *eval* falha\n- *Release notes* alargadas com versões agentic\n\n**⚖️ Proporcionalidade.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Recomendado | *Eval gate* simples; *rollback* de modelo pode partilhar pipeline com aplicação |\n| L2 | Sim para A1+ | *Eval gate* completo; *rollback* de modelo independente documentado; *canary* recomendado |\n| L3 | Sim para A1+ | *Eval gate* completo + *canary* obrigatório em mudança de versão maior + auditoria do `eval_run_id` |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Pré-promoção | *Eval gate* falha | DevOps + AppSec | Bloqueio imediato |\n| Promoção | Mudança de versão maior de modelo / prompt | DevOps + AppSec + *owner* do agente (Policy 38) | Janela *canary* declarada |\n| Degradação em produção | `OPS-011/013/014` dispara | Ops + AppSec | *Rollback* conforme nível de severidade |\n| Auditoria | `review_cadence` do *mandate* | AppSec | Conforme cadência |\n\n**Ligações úteis.**\n- 🔗 [Cap. 07 US-19 — Agentes na pipeline](/sbd-toe/sbd-manual/cicd-seguro/aplicacao-lifecycle)\n- 🔗 [Cap. 10 §C5 — Eval suites](/sbd-toe/sbd-manual/testes-seguranca/addon/ia-nos-testes#c5-eval-suites)\n- 🔗 [Cap. 12 — `OPS-011..014`](/sbd-toe/sbd-manual/monitorizacao-operacoes/addon/catalogo-requisitos-operacoes)\n- 🔗 [Cap. 12 US-13 — Telemetria agentic](/sbd-toe/sbd-manual/monitorizacao-operacoes/aplicacao-lifecycle)\n- 🔗 [Policy 38 §5.4 — Activação do mandate](/sbd-toe/assets/policies/policy-mandates-agentes)\n- 🔗 [Policy 39 §5 — Version pinning](/sbd-toe/assets/policies/policy-ai-bom-supply-chain)\n- 🔗 Grounding canónico: [`DPL-010` / `DPL-011`](./addon/catalogo-requisitos-deploy)\n\n---", "title": "US-18 - Release gates específicos para sistemas com agentes AI {#us-18}", "traceability": {"line_end": 804, "line_start": 736, "source_path": "010-sbd-manual/11-deploy-seguro/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-18-release-gates-especificos-para-sistemas-com-agentes-ai-us-18"}, "vector_text": "US-18 - Release gates específicos para sistemas com agentes AI {#us-18}\n\n### US-18 - Release gates específicos para sistemas com agentes AI {#us-18}\n\n**Contexto.**\nQuando o sistema inclui **agentes AI** ou um **modelo AI como dependência *load-bearing***, o *release* deixa de ser apenas \"novo binário aplicacional → produção\". Há três artefactos novos no caminho crítico que podem mudar comportamento sem o binário aplicacional mudar: **versão do modelo**, ***skill files* / *system prompts*** que dirigem o agente, e ***eval suite*** que sustenta a classificação de autonomia A0–A4. O *release* tem de tratar estes três como dimensões próprias, com *gates*, *rollback* independente e estratégia de *canary*.\n\n:::userstory\n**História.**\nComo **DevOps / SRE** e **AppSec**, quero que o *release* de sistemas com agentes AI tenha *gates* específicos — *eval suite* como gate; *rollback* de modelo independente do *rollback* aplicacional; *canary release* de versão de modelo — para garantir que mudanças que afectam o comportamento agentic são tão controláveis e reversíveis quanto mudanças de código.\n\n**Critérios de aceitação (BDD).**\n- **Dado** uma promoção para produção que altera modelo, *skill files* ou *system prompts*\n **Quando** o pipeline de *release* corre\n **Então** a *eval suite* (Cap. 10 §C5) corre como *gate* obrigatório; *fail* bloqueia a promoção\n- **Dado** que uma versão de modelo em produção apresenta degradação ([`OPS-011`](/sbd-toe/sbd-manual/monitorizacao-operacoes/addon/catalogo-requisitos-operacoes) *drift*, [`OPS-014`](/sbd-toe/sbd-manual/monitorizacao-operacoes/addon/catalogo-requisitos-operacoes#ops-014) *off-policy actions* aumentaram, [`OPS-013`](/sbd-toe/sbd-manual/monitorizacao-operacoes/addon/catalogo-requisitos-operacoes#ops-013) *budget overrun*)\n **Quando** se decide reverter\n **Então** existe procedimento de *rollback* da versão do modelo **sem** reverter o binário aplicacional (e vice-versa)\n- **Dado** uma mudança de versão maior do modelo (provider muda, novo *fine-tune*, ou novo *system prompt* com impacto material)\n **Quando** se promove para produção\n **Então** a estratégia é *canary* — fracção controlada de tráfego direccionada à nova versão durante janela observável, com critérios objectivos de promoção ou rollback\n- **Dado** um *mandate* de agente (Policy 38) com `autonomy_level` declarado\n **Quando** a *eval suite* falha ou o `m_recall` da cobertura desce abaixo do limiar\n **Então** o agente desce automaticamente para o nível inferior (e.g. A3 → A2) até resolução; não opera no nível pedido\n\n**Critérios de aceitação (DoD).**\n- [ ] *Eval suite* registada como *gate* obrigatório no pipeline (cross-link Cap. 07 [US-19](/sbd-toe/sbd-manual/cicd-seguro/aplicacao-lifecycle))\n- [ ] `eval_run_id` ligado ao *release* e arquivado como evidência\n- [ ] Procedimento de *rollback* de modelo independente documentado (revogar *deployment* do modelo no *artifact registry* / *model registry*, sem tocar no binário aplicacional)\n- [ ] Procedimento de *rollback* de *system prompt* / *skill file* independente (revert do *commit* dos *skill files* não obriga a redeploy aplicacional se o *runtime* lê dinamicamente do *registry*)\n- [ ] Estratégia *canary* configurada para promoções de modelo: fracção inicial (tipicamente 5–10%), critérios de promoção (taxa de erro, *off-policy events*, latência, *user satisfaction* quando disponível), critérios de *rollback* automático\n- [ ] *Gate* automático que desce o `autonomy_level` quando a *eval suite* não confirma o nível pretendido (cross-link [Policy 38](/sbd-toe/assets/policies/policy-mandates-agentes) §5.4)\n- [ ] *Release notes* incluem versão de modelo, versão de *skill files*, *eval suite* version, `mandate_ref`\n\n:::\n\n**🧾 Artefactos & evidências.**\n- *Pipeline manifest* com *eval gate* configurado\n- `eval_run_id` por *release* arquivado e correlacionado com `mandate_ref`\n- *Runbook* de *model rollback* (separado do *rollback* aplicacional)\n- *Runbook* de *prompt/skill rollback*\n- *Canary release plan* por mudança de versão maior de modelo, com critérios objectivos\n- *Logs* de *autonomy demotion* automático quando *eval* falha\n- *Release notes* alargadas com versões agentic\n\n**⚖️ Proporcionalidade.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Recomendado | *Eval gate* simples; *rollback* de modelo pode partilhar pipeline com aplicação |\n| L2 | Sim para A1+ | *Eval gate* completo; *rollback* de modelo independente documentado; *canary* recomendado |\n| L3 | Sim para A1+ | *Eval gate* completo + *canary* obrigatório em mudança de versão maior + auditoria do `eval_run_id` |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Pré-promoção | *Eval gate* falha | DevOps + AppSec | Bloqueio imediato |\n| Promoção | Mudança de versão maior de modelo / prompt | DevOps + AppSec + *owner* do agente (Policy 38) | Janela *canary* declarada |\n| Degradação em produção | `OPS-011/013/014` dispara | Ops + AppSec | *Rollback* conforme nível de severidade |\n| Auditoria | `review_cadence` do *mandate* | AppSec | Conforme cadência |\n\n**Ligações úteis.**\n- 🔗 [Cap. 07 US-19 — Agentes na pipeline](/sbd-toe/sbd-manual/cicd-seguro/aplicacao-lifecycle)\n- 🔗 [Cap. 10 §C5 — Eval suites](/sbd-toe/sbd-manual/testes-seguranca/addon/ia-nos-testes#c5-eval-suites)\n- 🔗 [Cap. 12 — `OPS-011..014`](/sbd-toe/sbd-manual/monitorizacao-operacoes/addon/catalogo-requisitos-operacoes)\n- 🔗 [Cap. 12 US-13 — Telemetria agentic](/sbd-toe/sbd-manual/monitorizacao-operacoes/aplicacao-lifecycle)\n- 🔗 [Policy 38 §5.4 — Activação do mandate](/sbd-toe/assets/policies/policy-mandates-agentes)\n- 🔗 [Policy 39 §5 — Version pinning](/sbd-toe/assets/policies/policy-ai-bom-supply-chain)\n- 🔗 Grounding canónico: [`DPL-010` / `DPL-011`](./addon/catalogo-requisitos-deploy)\n\n---"}
|
|
2936
|
+
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-19-credenciais-de-deploy-isoladas-por-aplicacao-e-efemeras", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": ["secure-deploy"], "phase": ["deploy"], "risk_level": ["L1", "L2", "L3"]}, "mentioned_entities": {"Requirement": ["DPL-006"], "UserStory": ["US-08", "US-19"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-19-credenciais-de-deploy-isoladas-por-aplicacao-e-efemeras", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📦 Artefactos esperados", "US-19 - Credenciais de *deploy* isoladas por aplicação e efémeras"], "size_estimate": {"approx_tokens": 719, "chars": 2875}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-19 - Credenciais de *deploy* isoladas por aplicação e efémeras\n\nUma credencial de *deploy* partilhada transforma o compromisso de um pipeline no compromisso de todos os que ela alcança. \n\n**Contexto.** As credenciais usadas no momento do *deploy* combinam acesso privilegiado a ambientes de produção com automação não-supervisionada. Quando são permanentes ou partilhadas entre aplicações, um único *token* exfiltrado dá movimento lateral a todo o portfólio e torna impossível atribuir uso indevido a uma aplicação concreta. A US-08 cobre segredos *aplicacionais* injetados em *runtime*; esta US trata as credenciais *do pipeline de deploy* — âmbito mínimo, vida curta e isolamento por aplicação (`DPL-006`). \n\n:::userstory\n**História.** \nComo **DevOps/SRE**, quero **que cada aplicação use credenciais de *deploy* próprias, de âmbito mínimo e curta duração, nunca partilhadas entre aplicações**, para **conter o raio de impacto de uma credencial comprometida e tornar o uso atribuível e auditável**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** um pipeline de *deploy* de uma aplicação \n **Quando** o pipeline se autentica para promover a produção \n **Então** usa uma identidade efémera por execução (OIDC / *workload identity*), sem chaves persistentes \n- **Dado** o conjunto de credenciais de *deploy* do portfólio \n **Quando** se audita o seu âmbito \n **Então** nenhuma credencial de *deploy* é partilhada entre aplicações e cada uma tem apenas as permissões necessárias ao seu alvo \n- **Dado** uma promoção a produção \n **Quando** a credencial é usada \n **Então** o uso fica registado (identidade, aplicação, timestamp, ambiente) e correlacionável com o *deploy* \n\n**Checklist.** \n- [ ] OIDC / *workload identity* configurado (sem chaves de longa duração no *deploy*) \n- [ ] Credenciais de *deploy* distintas por aplicação (sem partilha entre apps) \n- [ ] Âmbito mínimo por credencial (permissões limitadas ao alvo) \n- [ ] Logs de uso de credenciais centralizados e correlacionáveis com o *deploy* \n\n:::\n\n**Artefactos & evidências.** Configuração de *workload identity*/OIDC por pipeline, inventário de credenciais de *deploy* por aplicação, logs de uso de credenciais. \n\n**Proporcionalidade L1–L3.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Âmbito mínimo documentado; sem partilha entre apps | OIDC/*workload identity* (tokens efémeros); isolamento por app | OIDC obrigatório + auditoria periódica de âmbito e logs de uso |\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|------|---------|-------------|-----|\n| Build/Deploy | Autenticação do pipeline | DevOps/SRE | Cada deploy |\n\n**Ligações úteis.** [Catálogo DPL-006](/sbd-toe/sbd-manual/deploy-seguro/addon/catalogo-requisitos-deploy) · [CI/CD Seguro](/sbd-toe/sbd-manual/cicd-seguro/intro)\n\n---", "title": "US-19 - Credenciais de *deploy* isoladas por aplicação e efémeras", "traceability": {"line_end": 849, "line_start": 805, "source_path": "010-sbd-manual/11-deploy-seguro/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-19-credenciais-de-deploy-isoladas-por-aplicacao-e-efemeras"}, "vector_text": "US-19 - Credenciais de *deploy* isoladas por aplicação e efémeras\n\n### US-19 - Credenciais de *deploy* isoladas por aplicação e efémeras\n\nUma credencial de *deploy* partilhada transforma o compromisso de um pipeline no compromisso de todos os que ela alcança. \n\n**Contexto.** As credenciais usadas no momento do *deploy* combinam acesso privilegiado a ambientes de produção com automação não-supervisionada. Quando são permanentes ou partilhadas entre aplicações, um único *token* exfiltrado dá movimento lateral a todo o portfólio e torna impossível atribuir uso indevido a uma aplicação concreta. A US-08 cobre segredos *aplicacionais* injetados em *runtime*; esta US trata as credenciais *do pipeline de deploy* — âmbito mínimo, vida curta e isolamento por aplicação (`DPL-006`). \n\n:::userstory\n**História.** \nComo **DevOps/SRE**, quero **que cada aplicação use credenciais de *deploy* próprias, de âmbito mínimo e curta duração, nunca partilhadas entre aplicações**, para **conter o raio de impacto de uma credencial comprometida e tornar o uso atribuível e auditável**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** um pipeline de *deploy* de uma aplicação \n **Quando** o pipeline se autentica para promover a produção \n **Então** usa uma identidade efémera por execução (OIDC / *workload identity*), sem chaves persistentes \n- **Dado** o conjunto de credenciais de *deploy* do portfólio \n **Quando** se audita o seu âmbito \n **Então** nenhuma credencial de *deploy* é partilhada entre aplicações e cada uma tem apenas as permissões necessárias ao seu alvo \n- **Dado** uma promoção a produção \n **Quando** a credencial é usada \n **Então** o uso fica registado (identidade, aplicação, timestamp, ambiente) e correlacionável com o *deploy* \n\n**Checklist.** \n- [ ] OIDC / *workload identity* configurado (sem chaves de longa duração no *deploy*) \n- [ ] Credenciais de *deploy* distintas por aplicação (sem partilha entre apps) \n- [ ] Âmbito mínimo por credencial (permissões limitadas ao alvo) \n- [ ] Logs de uso de credenciais centralizados e correlacionáveis com o *deploy* \n\n:::\n\n**Artefactos & evidências.** Configuração de *workload identity*/OIDC por pipeline, inventário de credenciais de *deploy* por aplicação, logs de uso de credenciais. \n\n**Proporcionalidade L1–L3.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Âmbito mínimo documentado; sem partilha entre apps | OIDC/*workload identity* (tokens efémeros); isolamento por app | OIDC obrigatório + auditoria periódica de âmbito e logs de uso |\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|------|---------|-------------|-----|\n| Build/Deploy | Autenticação do pipeline | DevOps/SRE | Cada deploy |\n\n**Ligações úteis.** [Catálogo DPL-006](/sbd-toe/sbd-manual/deploy-seguro/addon/catalogo-requisitos-deploy) · [CI/CD Seguro](/sbd-toe/sbd-manual/cicd-seguro/intro)\n\n---"}
|
|
2937
|
+
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-20-feature-flags-avaliadas-no-backend-como-fronteira-de-confianca", "chunk_kind": "user_story", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-07", "US-20"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-20-feature-flags-avaliadas-no-backend-como-fronteira-de-confianca", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "📦 Artefactos esperados", "US-20 - *Feature flags* avaliadas no *backend* como fronteira de confiança"], "size_estimate": {"approx_tokens": 715, "chars": 2859}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-20 - *Feature flags* avaliadas no *backend* como fronteira de confiança\n\nUm *toggle* avaliado no cliente não controla nada: protege apenas o que o utilizador escolhe não contornar. \n\n**Contexto.** *Feature flags* que decidem exposição de funcionalidades sensíveis têm de ser avaliadas no *backend*. A avaliação *client-side* é manipulável pela UI e permite *bypass* trivial; e um *toggle* nunca substitui controlo de acesso. A US-07 cobre o ciclo de vida da *flag* (metadata, *owner*, expiração, versionamento como código); esta US trata a propriedade de segurança da avaliação — onde a decisão é tomada e como o *fallback* é validado. \n\n:::userstory\n**História.** \nComo **Dev/AppSec**, quero **que toggles que controlam lógica sensível sejam avaliados no *backend*, nunca apenas no *frontend*, e nunca como substituto de controlo de acesso**, para **impedir *bypass* via manipulação da UI e garantir que a fronteira de confiança é o servidor**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** um *toggle* que controla uma funcionalidade ou fluxo sensível \n **Quando** a funcionalidade é solicitada \n **Então** a decisão de ativação é avaliada e imposta no *backend* (a UI não é a fronteira de decisão) \n- **Dado** um *toggle* manipulado no cliente (UI/parâmetro) \n **Quando** o pedido chega ao servidor \n **Então** o *backend* impõe o estado correto e o *bypass* não tem efeito \n- **Dado** um *toggle* crítico \n **Quando** está ativo e quando está desligado \n **Então** ambos os caminhos lógicos (com e sem *toggle*) são testáveis e têm *fallback* definido \n\n**Checklist.** \n- [ ] *Toggles* de lógica sensível avaliados no *backend* (não apenas *frontend*) \n- [ ] *Toggle* não usado como substituto de controlo de acesso (autorização independente) \n- [ ] Caminhos com e sem *toggle* testáveis, com *fallback* definido \n- [ ] Avaliação/alteração de *toggle* registada em logs (não silenciosa) \n\n:::\n\n**Artefactos & evidências.** Evidência de avaliação *server-side* (código/configuração), testes dos caminhos com e sem *toggle*, logs de avaliação de *toggle*. \n\n**Proporcionalidade L1–L3.** \n| L1 | L2 | L3 |\n|----|----|----|\n| *Backend* para *toggles* sensíveis; *fallback* documentado | *Backend* para todos os *toggles* de lógica; ambos os caminhos testados | *Backend* + autorização independente + logs auditáveis de avaliação |\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|------|---------|-------------|-----|\n| Desenvolvimento/Deploy | Introdução ou alteração de *toggle* sensível | Dev + AppSec | Cada PR de *toggle* |\n\n**Ligações úteis.** [Feature Flags e Toggles](/sbd-toe/sbd-manual/deploy-seguro/addon/03-feature-flags-e-toggle) · [Monitorização & Operações](/sbd-toe/sbd-manual/monitorizacao-operacoes/intro)\n\n---", "title": "US-20 - *Feature flags* avaliadas no *backend* como fronteira de confiança", "traceability": {"line_end": 894, "line_start": 850, "source_path": "010-sbd-manual/11-deploy-seguro/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--artefactos-esperados--us-20-feature-flags-avaliadas-no-backend-como-fronteira-de-confianca"}, "vector_text": "US-20 - *Feature flags* avaliadas no *backend* como fronteira de confiança\n\n### US-20 - *Feature flags* avaliadas no *backend* como fronteira de confiança\n\nUm *toggle* avaliado no cliente não controla nada: protege apenas o que o utilizador escolhe não contornar. \n\n**Contexto.** *Feature flags* que decidem exposição de funcionalidades sensíveis têm de ser avaliadas no *backend*. A avaliação *client-side* é manipulável pela UI e permite *bypass* trivial; e um *toggle* nunca substitui controlo de acesso. A US-07 cobre o ciclo de vida da *flag* (metadata, *owner*, expiração, versionamento como código); esta US trata a propriedade de segurança da avaliação — onde a decisão é tomada e como o *fallback* é validado. \n\n:::userstory\n**História.** \nComo **Dev/AppSec**, quero **que toggles que controlam lógica sensível sejam avaliados no *backend*, nunca apenas no *frontend*, e nunca como substituto de controlo de acesso**, para **impedir *bypass* via manipulação da UI e garantir que a fronteira de confiança é o servidor**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** um *toggle* que controla uma funcionalidade ou fluxo sensível \n **Quando** a funcionalidade é solicitada \n **Então** a decisão de ativação é avaliada e imposta no *backend* (a UI não é a fronteira de decisão) \n- **Dado** um *toggle* manipulado no cliente (UI/parâmetro) \n **Quando** o pedido chega ao servidor \n **Então** o *backend* impõe o estado correto e o *bypass* não tem efeito \n- **Dado** um *toggle* crítico \n **Quando** está ativo e quando está desligado \n **Então** ambos os caminhos lógicos (com e sem *toggle*) são testáveis e têm *fallback* definido \n\n**Checklist.** \n- [ ] *Toggles* de lógica sensível avaliados no *backend* (não apenas *frontend*) \n- [ ] *Toggle* não usado como substituto de controlo de acesso (autorização independente) \n- [ ] Caminhos com e sem *toggle* testáveis, com *fallback* definido \n- [ ] Avaliação/alteração de *toggle* registada em logs (não silenciosa) \n\n:::\n\n**Artefactos & evidências.** Evidência de avaliação *server-side* (código/configuração), testes dos caminhos com e sem *toggle*, logs de avaliação de *toggle*. \n\n**Proporcionalidade L1–L3.** \n| L1 | L2 | L3 |\n|----|----|----|\n| *Backend* para *toggles* sensíveis; *fallback* documentado | *Backend* para todos os *toggles* de lógica; ambos os caminhos testados | *Backend* + autorização independente + logs auditáveis de avaliação |\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|------|---------|-------------|-----|\n| Desenvolvimento/Deploy | Introdução ou alteração de *toggle* sensível | Dev + AppSec | Cada PR de *toggle* |\n\n**Ligações úteis.** [Feature Flags e Toggles](/sbd-toe/sbd-manual/deploy-seguro/addon/03-feature-flags-e-toggle) · [Monitorização & Operações](/sbd-toe/sbd-manual/monitorizacao-operacoes/intro)\n\n---"}
|
|
2938
|
+
{"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--matriz-de-proporcionalidade-l1l3", "chunk_kind": "table_section", "document_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "11-deploy-seguro", "chunk_kind": "table_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--matriz-de-proporcionalidade-l1l3", "relation_hints": [], "section_path": ["Aplicação de Deploy Seguro no Ciclo de Vida", "⚖️ Matriz de proporcionalidade L1–L3"], "size_estimate": {"approx_tokens": 167, "chars": 666}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## ⚖️ Matriz de proporcionalidade L1–L3\n\nNem todas as aplicações exigem o mesmo nível de controlo. \nA proporcionalidade permite adaptar rigor sem comprometer segurança:\n\n| Prática | L1 | L2 | L3 |\n|---------|----|----|----|\n| Deploy de artefactos assinados | Recomendado | Obrigatório | Obrigatório + rejeição automática |\n| Validação em *staging* | Opcional | Recomendado | Obrigatório |\n| *Gates* de aprovação | Aviso | Bloqueio High/Critical | Bloqueio Medium+ |\n| *Rollback* | Manual | Automatizado | Automatizado + testado |\n| Rastreabilidade | Básica | Completa | Completa + auditoria |\n| Monitorização | Básica | Crítica", "title": "⚖️ Matriz de proporcionalidade L1–L3", "traceability": {"line_end": 907, "line_start": 895, "source_path": "010-sbd-manual/11-deploy-seguro/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-11-deploy-seguro-aplicacao-lifecycle--aplicacao-de-deploy-seguro-no-ciclo-de-vida--matriz-de-proporcionalidade-l1l3"}, "vector_text": "⚖️ Matriz de proporcionalidade L1–L3\n\n## ⚖️ Matriz de proporcionalidade L1–L3\n\nNem todas as aplicações exigem o mesmo nível de controlo. \nA proporcionalidade permite adaptar rigor sem comprometer segurança:\n\n| Prática | L1 | L2 | L3 |\n|---------|----|----|----|\n| Deploy de artefactos assinados | Recomendado | Obrigatório | Obrigatório + rejeição automática |\n| Validação em *staging* | Opcional | Recomendado | Obrigatório |\n| *Gates* de aprovação | Aviso | Bloqueio High/Critical | Bloqueio Medium+ |\n| *Rollback* | Manual | Automatizado | Automatizado + testado |\n| Rastreabilidade | Básica | Completa | Completa + auditoria |\n| Monitorização | Básica | Crítica"}
|
|
2939
2939
|
{"authority_class": "historical", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-canon-20-checklist-revisao--checklist-de-revisao-periodica-deploy-seguro", "chunk_kind": "narrative_section", "document_id": "010-sbd-manual-11-deploy-seguro-canon-20-checklist-revisao", "document_role": "legacy_canon", "filter_tags": {"authority_class": "historical", "bundle_id": "11-deploy-seguro", "chunk_kind": "narrative_section", "document_role": "legacy_canon", "domain": ["secure-deploy"], "phase": ["deploy"], "risk_level": ["L1", "L2", "L3"]}, "mentioned_entities": {"Requirement": ["DPL-001", "DPL-009"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-canon-20-checklist-revisao--checklist-de-revisao-periodica-deploy-seguro", "relation_hints": [], "section_path": ["Checklist de Revisão Periódica - Deploy Seguro"], "size_estimate": {"approx_tokens": 171, "chars": 681}, "source_mode": "explicit", "support_profiles": ["implementation"], "text": "# Checklist de Revisão Periódica - Deploy Seguro\n\nEste checklist aplica-se a todas as aplicações em vias de serem colocadas em produção, especialmente as classificadas como L2 ou L3.\nServe como instrumento de verificação binária e auditável da **adoção prática das prescrições do Capítulo 11** (`DPL-001` a `DPL-009`), permitindo:\n\n- Controlo formal da execução segura\n- Verificação da existência de rollback testado\n- Confirmação da validação operacional antes do deploy\n\n> 🗓️ **Recomenda-se a sua revisão antes de qualquer release, rollback ou alteração de configuração relevante**, conforme indicado na `aplicacao-lifecycle`.\n\n---", "title": "Checklist de Revisão Periódica - Deploy Seguro", "traceability": {"line_end": 22, "line_start": 10, "source_path": "010-sbd-manual/11-deploy-seguro/canon/20-checklist-revisao.md", "unit_id": "010-sbd-manual-11-deploy-seguro-canon-20-checklist-revisao--checklist-de-revisao-periodica-deploy-seguro"}, "vector_text": "Checklist de Revisão Periódica - Deploy Seguro\n\n# Checklist de Revisão Periódica - Deploy Seguro\n\nEste checklist aplica-se a todas as aplicações em vias de serem colocadas em produção, especialmente as classificadas como L2 ou L3.\nServe como instrumento de verificação binária e auditável da **adoção prática das prescrições do Capítulo 11** (`DPL-001` a `DPL-009`), permitindo:\n\n- Controlo formal da execução segura\n- Verificação da existência de rollback testado\n- Confirmação da validação operacional antes do deploy\n\n> 🗓️ **Recomenda-se a sua revisão antes de qualquer release, rollback ou alteração de configuração relevante**, conforme indicado na `aplicacao-lifecycle`.\n\n---"}
|
|
2940
2940
|
{"authority_class": "historical", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-canon-20-checklist-revisao--checklist-de-revisao-periodica-deploy-seguro--itens-de-verificacao", "chunk_kind": "table_section", "document_id": "010-sbd-manual-11-deploy-seguro-canon-20-checklist-revisao", "document_role": "legacy_canon", "filter_tags": {"authority_class": "historical", "bundle_id": "11-deploy-seguro", "chunk_kind": "table_section", "document_role": "legacy_canon", "domain": ["secure-deploy"], "phase": ["deploy"], "risk_level": ["L1", "L2", "L3"]}, "mentioned_entities": {"Requirement": ["DPL-001", "DPL-002", "DPL-003", "DPL-004", "DPL-005", "DPL-006", "DPL-007", "DPL-008", "DPL-009", "DPL-010", "DPL-011"]}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-canon-20-checklist-revisao--checklist-de-revisao-periodica-deploy-seguro--itens-de-verificacao", "relation_hints": [], "section_path": ["Checklist de Revisão Periódica - Deploy Seguro", "📋 Itens de Verificação"], "size_estimate": {"approx_tokens": 856, "chars": 3424}, "source_mode": "explicit", "support_profiles": ["implementation"], "text": "## 📋 Itens de Verificação\n\n| Item | Verificado? |\n|---------------------------------------------------------------------------------------------------|-------------|\n| Existe aprovação formal humana do deploy registada com timestamp e identidade do aprovador? (`DPL-001`) | ☐ |\n| Os artefactos promovidos têm assinatura/hash e proveniência (commit SHA, run id) verificados no deploy, com rejeição automática dos que não a têm? (`DPL-002`) | ☐ |\n| Os gates automáticos de segurança (CVEs críticos, testes, secret scanning) bloqueiam o deploy em caso de falha, com evidência de execução? (`DPL-003`) | ☐ |\n| As validações estão integradas em gates condicionais parametrizados por criticidade (L1–L3)? | ☐ |\n| Existe SBOM atualizado ligado ao artefacto e todos os findings estão resolvidos ou com exceção formal aprovada (aprovador e validade)? | ☐ |\n| Cada deploy tem ID único e registo que associa quem aprovou, artefacto, commit SHA, momento, ambiente e gates, permitindo traçar de incidente a commit? (`DPL-004`) | ☐ |\n| Existe procedimento de rollback documentado e testado no último ciclo de release ou ano, com data e tempo máximo verificados? (`DPL-005`) | ☐ |\n| Existem mecanismos de reversibilidade imediata (blue/green, toggles), com releases anteriores documentadas e reversíveis? (`DPL-009`) | ☐ |\n| As credenciais de deploy têm âmbito mínimo e vida curta (OIDC/workload identity), não partilhadas entre aplicações, com logs de uso? (`DPL-006`) | ☐ |\n| A validação em staging representativo (mesmas versões/configuração, dados não reais) foi executada antes da promoção (L2/L3)? (`DPL-007`) | ☐ |\n| A pipeline de produção está segregada, com segredos em cofres distintos e acesso por MFA e RBAC? | ☐ |\n| Existe monitorização durante a janela de deploy e período de observação pós-deploy por nível, com thresholds para rollback automático e playbook de reação por incidente? (`DPL-008`) | ☐ |\n| Para componentes críticos, o deploy é progressivo (canary, blue-green ou feature flags) com thresholds e critérios de rollback por etapa (L3)? (`DPL-009`) | ☐ |\n| As feature flags têm metadata obrigatória (owner, âmbito, ativação, expiração), são versionadas como código, auditáveis, avaliadas no backend e revistas periodicamente? | ☐ |\n| A release segue versionamento semântico com changelog técnico e de segurança (CVEs corrigidas, breaking changes)? | ☐ |\n| As exceções a gates seguem template versionado (aprovador por severidade, validade máx. 6 meses), e as ações irreversíveis e decisões de go/no-go exigem registo humano (quem, quando, porquê, evidência)? | ☐ |\n| Em sistemas com agente AI ou modelo *load-bearing*, a *eval suite* corre como gate obrigatório quando muda modelo/*skill files*/*system prompts*, o *rollback* de modelo e de *prompt/skill* é independente do aplicacional, e as *release notes* registam versão de modelo/skill/eval + `mandate_ref` (`DPL-010`)? | ☐ |\n| Em sistemas agentic L3, a mudança de versão maior de modelo é promovida via *canary* com critérios objetivos, e existe gate automático que desce o `autonomy_level` quando a *eval suite* não confirma o nível (`DPL-011`)? | ☐ |\n\n---", "title": "📋 Itens de Verificação", "traceability": {"line_end": 47, "line_start": 23, "source_path": "010-sbd-manual/11-deploy-seguro/canon/20-checklist-revisao.md", "unit_id": "010-sbd-manual-11-deploy-seguro-canon-20-checklist-revisao--checklist-de-revisao-periodica-deploy-seguro--itens-de-verificacao"}, "vector_text": "📋 Itens de Verificação\n\n## 📋 Itens de Verificação\n\n| Item | Verificado? |\n|---------------------------------------------------------------------------------------------------|-------------|\n| Existe aprovação formal humana do deploy registada com timestamp e identidade do aprovador? (`DPL-001`) | ☐ |\n| Os artefactos promovidos têm assinatura/hash e proveniência (commit SHA, run id) verificados no deploy, com rejeição automática dos que não a têm? (`DPL-002`) | ☐ |\n| Os gates automáticos de segurança (CVEs críticos, testes, secret scanning) bloqueiam o deploy em caso de falha, com evidência de execução? (`DPL-003`) | ☐ |\n| As validações estão integradas em gates condicionais parametrizados por criticidade (L1–L3)? | ☐ |\n| Existe SBOM atualizado ligado ao artefacto e todos os findings estão resolvidos ou com exceção formal aprovada (aprovador e validade)? | ☐ |\n| Cada deploy tem ID único e registo que associa quem aprovou, artefacto, commit SHA, momento, ambiente e gates, permitindo traçar de incidente a commit? (`DPL-004`) | ☐ |\n| Existe procedimento de rollback documentado e testado no último ciclo de release ou ano, com data e tempo máximo verificados? (`DPL-005`) | ☐ |\n| Existem mecanismos de reversibilidade imediata (blue/green, toggles), com releases anteriores documentadas e reversíveis? (`DPL-009`) | ☐ |\n| As credenciais de deploy têm âmbito mínimo e vida curta (OIDC/workload identity), não partilhadas entre aplicações, com logs de uso? (`DPL-006`) | ☐ |\n| A validação em staging representativo (mesmas versões/configuração, dados não reais) foi executada antes da promoção (L2/L3)? (`DPL-007`) | ☐ |\n| A pipeline de produção está segregada, com segredos em cofres distintos e acesso por MFA e RBAC? | ☐ |\n| Existe monitorização durante a janela de deploy e período de observação pós-deploy por nível, com thresholds para rollback automático e playbook de reação por incidente? (`DPL-008`) | ☐ |\n| Para componentes críticos, o deploy é progressivo (canary, blue-green ou feature flags) com thresholds e critérios de rollback por etapa (L3)? (`DPL-009`) | ☐ |\n| As feature flags têm metadata obrigatória (owner, âmbito, ativação, expiração), são versionadas como código, auditáveis, avaliadas no backend e revistas periodicamente? | ☐ |\n| A release segue versionamento semântico com changelog técnico e de segurança (CVEs corrigidas, breaking changes)? | ☐ |\n| As exceções a gates seguem template versionado (aprovador por severidade, validade máx. 6 meses), e as ações irreversíveis e decisões de go/no-go exigem registo humano (quem, quando, porquê, evidência)? | ☐ |\n| Em sistemas com agente AI ou modelo *load-bearing*, a *eval suite* corre como gate obrigatório quando muda modelo/*skill files*/*system prompts*, o *rollback* de modelo e de *prompt/skill* é independente do aplicacional, e as *release notes* registam versão de modelo/skill/eval + `mandate_ref` (`DPL-010`)? | ☐ |\n| Em sistemas agentic L3, a mudança de versão maior de modelo é promovida via *canary* com critérios objetivos, e existe gate automático que desce o `autonomy_level` quando a *eval suite* não confirma o nível (`DPL-011`)? | ☐ |\n\n---"}
|
|
2941
2941
|
{"authority_class": "historical", "bundle_id": "11-deploy-seguro", "chunk_id": "010-sbd-manual-11-deploy-seguro-canon-20-checklist-revisao--checklist-de-revisao-periodica-deploy-seguro--integracao-operacional", "chunk_kind": "narrative_section", "document_id": "010-sbd-manual-11-deploy-seguro-canon-20-checklist-revisao", "document_role": "legacy_canon", "filter_tags": {"authority_class": "historical", "bundle_id": "11-deploy-seguro", "chunk_kind": "narrative_section", "document_role": "legacy_canon", "domain": [], "phase": ["deploy"], "risk_level": []}, "mentioned_entities": {}, "record_id": "mcp::010-sbd-manual-11-deploy-seguro-canon-20-checklist-revisao--checklist-de-revisao-periodica-deploy-seguro--integracao-operacional", "relation_hints": [], "section_path": ["Checklist de Revisão Periódica - Deploy Seguro", "🔄 Integração Operacional"], "size_estimate": {"approx_tokens": 135, "chars": 540}, "source_mode": "explicit", "support_profiles": ["implementation"], "text": "## 🔄 Integração Operacional\n\n- Este checklist pode ser integrado em **pipelines, fluxos de aprovação de release, gates de produção ou auditorias técnicas**.\n- Cada item deve ser validado com **evidência objetiva** (ex: logs de aprovação, ficheiros SBOM, relatórios de rollback, prints do pipeline).\n- Os resultados podem ser ligados ao ciclo de vida do artefacto, da aplicação ou do serviço.\n\n> ⚠️ Em caso de resposta negativa, deve existir exceção formal aprovada e documentada conforme o modelo do capítulo.\n\n---", "title": "🔄 Integração Operacional", "traceability": {"line_end": 57, "line_start": 48, "source_path": "010-sbd-manual/11-deploy-seguro/canon/20-checklist-revisao.md", "unit_id": "010-sbd-manual-11-deploy-seguro-canon-20-checklist-revisao--checklist-de-revisao-periodica-deploy-seguro--integracao-operacional"}, "vector_text": "🔄 Integração Operacional\n\n## 🔄 Integração Operacional\n\n- Este checklist pode ser integrado em **pipelines, fluxos de aprovação de release, gates de produção ou auditorias técnicas**.\n- Cada item deve ser validado com **evidência objetiva** (ex: logs de aprovação, ficheiros SBOM, relatórios de rollback, prints do pipeline).\n- Os resultados podem ser ligados ao ciclo de vida do artefacto, da aplicação ou do serviço.\n\n> ⚠️ Em caso de resposta negativa, deve existir exceção formal aprovada e documentada conforme o modelo do capítulo.\n\n---"}
|
|
@@ -3680,32 +3680,32 @@
|
|
|
3680
3680
|
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--quando-aplicar", "chunk_kind": "table_section", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "table_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--quando-aplicar", "relation_hints": [], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "🧭 Quando aplicar"], "size_estimate": {"approx_tokens": 127, "chars": 507}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## 🧭 Quando aplicar\n\n| Fase / Evento | Ação esperada | Evidência |\n|---------------|--------------|-----------|\n| Planeamento | Definir cláusulas contratuais e métricas | Documentos aprovados |\n| Execução | Registar exceções, aplicar cláusulas em fornecedores | Registo GRC |\n| Validação | Auditorias a fornecedores, revisões de exceções | Relatórios de auditoria |\n| Operações | Reporting contínuo de KPIs | Dashboards |\n| Auditoria | Revisão organizacional | Relatório consolidado |\n\n---", "title": "🧭 Quando aplicar", "traceability": {"line_end": 22, "line_start": 11, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--quando-aplicar"}, "vector_text": "🧭 Quando aplicar\n\n## 🧭 Quando aplicar\n\n| Fase / Evento | Ação esperada | Evidência |\n|---------------|--------------|-----------|\n| Planeamento | Definir cláusulas contratuais e métricas | Documentos aprovados |\n| Execução | Registar exceções, aplicar cláusulas em fornecedores | Registo GRC |\n| Validação | Auditorias a fornecedores, revisões de exceções | Relatórios de auditoria |\n| Operações | Reporting contínuo de KPIs | Dashboards |\n| Auditoria | Revisão organizacional | Relatório consolidado |\n\n---"}
|
|
3681
3681
|
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--quem-executa-cada-acao", "chunk_kind": "table_section", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "table_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--quem-executa-cada-acao", "relation_hints": [], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "👥 Quem executa cada ação"], "size_estimate": {"approx_tokens": 134, "chars": 535}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## 👥 Quem executa cada ação\n\n| Papel | Responsabilidade |\n|-------|------------------|\n| **Developer** | Registar exceções e cumprir políticas |\n| **AppSec Engineer** | Validar exceções, supervisionar rastreabilidade |\n| **DevOps / SRE** | Assegurar execução técnica conforme cláusulas |\n| **Gestão Executiva** | Aprovar risco residual |\n| **GRC / Compliance (Procurement + Jurídico)** | Integrar cláusulas de segurança em contratos |\n| **GRC / Compliance** | Consolidar métricas e auditar fornecedores |\n\n---", "title": "👥 Quem executa cada ação", "traceability": {"line_end": 35, "line_start": 23, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--quem-executa-cada-acao"}, "vector_text": "👥 Quem executa cada ação\n\n## 👥 Quem executa cada ação\n\n| Papel | Responsabilidade |\n|-------|------------------|\n| **Developer** | Registar exceções e cumprir políticas |\n| **AppSec Engineer** | Validar exceções, supervisionar rastreabilidade |\n| **DevOps / SRE** | Assegurar execução técnica conforme cláusulas |\n| **Gestão Executiva** | Aprovar risco residual |\n| **GRC / Compliance (Procurement + Jurídico)** | Integrar cláusulas de segurança em contratos |\n| **GRC / Compliance** | Consolidar métricas e auditar fornecedores |\n\n---"}
|
|
3682
3682
|
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas", "chunk_kind": "narrative_section", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "narrative_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas", "relation_hints": [], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📖 User Stories normalizadas"], "size_estimate": {"approx_tokens": 15, "chars": 59}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## 📖 User Stories normalizadas", "title": "📖 User Stories normalizadas", "traceability": {"line_end": 37, "line_start": 36, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas"}, "vector_text": "📖 User Stories normalizadas\n\n## 📖 User Stories normalizadas"}
|
|
3683
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-01-processo-formal-de-excecoes-com-alcadas-por-nivel-de-risco", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-01"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-01-processo-formal-de-excecoes-com-alcadas-por-nivel-de-risco", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📖 User Stories normalizadas", "US-01 - Processo formal de exceções com alçadas por nível de risco"], "size_estimate": {"approx_tokens":
|
|
3684
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-02-clausulas-contratuais-de-seguranca", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-02"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-02-clausulas-contratuais-de-seguranca", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📖 User Stories normalizadas", "US-02 - Cláusulas contratuais de segurança"], "size_estimate": {"approx_tokens":
|
|
3685
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-03-validacao-continua-de-fornecedores", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-03"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-03-validacao-continua-de-fornecedores", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📖 User Stories normalizadas", "US-03 - Validação contínua de fornecedores"], "size_estimate": {"approx_tokens":
|
|
3686
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-04-rastreabilidade-organizacional", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-04"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-04-rastreabilidade-organizacional", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📖 User Stories normalizadas", "US-04 - Rastreabilidade organizacional"], "size_estimate": {"approx_tokens":
|
|
3687
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global", "chunk_kind": "checklist_section", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "checklist_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-01", "US-02", "US-03", "US-04", "US-06", "US-07"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global", "relation_hints": [], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global"], "size_estimate": {"approx_tokens": 377, "chars": 1507}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## 📊 Matriz de Rastreabilidade Global\n\nA tabela seguinte consolida as práticas de rastreabilidade aplicadas em cada capítulo, mostrando o ponto focal para auditoria e governação:\n\n| Capítulo | US | Contexto | Artefacto principal | Responsável |\n|----------|----|---------|--------------------|-------------|\n| **Cap 02** | US-07 | Requisitos com tags `SEC-Lx-*` | Backlog com rastreabilidade | QA / Product Owner |\n| **Cap 07** | US-03 | Logs e correlação commit-build-release | Relatórios CI/CD + audit trail | DevOps / SRE |\n| **Cap 08** | US-02 | Módulos versionados e rastreáveis | Histórico de módulos IaC | DevOps / SRE |\n| **Cap 09** | US-06 | SBOM com proveniência por imagem | `sbom.json` + metadados | DevOps / SRE |\n| **Cap 11** | US-02 | Rastreabilidade ponta-a-ponta (build → deploy → runtime) | Attestations + logs de deploy | DevOps / SRE |\n| **Cap 12** | US-01 | Eventos de segurança correlacionados | Eventos + logs SIEM | Operações (Ops) / AppSec Engineer |\n| **Cap 14** | US-04 | Dashboard organizacional de métricas | Dashboard + relatórios trimestrais | AppSec Engineer + GRC / Compliance |\n\n**Notas:**\n- Cada capítulo tem **um ponto focal de rastreabilidade** que se integra na matriz organizacional\n- **Cap 14 - US-04** agrega dados de todos os capítulos para visibilidade executiva\n- Todos os artefactos devem ser **versionados** e **auditáveis** conforme nível L1–L3\n- **SLA mínimo:** Relatórios mensais (L1), quinzenais (L2), contínuos (L3)\n\n---", "title": "📊 Matriz de Rastreabilidade Global", "traceability": {"line_end":
|
|
3688
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-05-kpis-de-governacao", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-05"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-05-kpis-de-governacao", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-05 - KPIs de governação"], "size_estimate": {"approx_tokens":
|
|
3689
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-06-execucao-de-fluxo-formal-de-validacao-de-fornecedores", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-06"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-06-execucao-de-fluxo-formal-de-validacao-de-fornecedores", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-06 - Execução de fluxo formal de validação de fornecedores"], "size_estimate": {"approx_tokens":
|
|
3690
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-07-ciclo-continuo-de-revisao-e-reavaliacao-de-excecoes", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-07"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-07-ciclo-continuo-de-revisao-e-reavaliacao-de-excecoes", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-07 - Ciclo contínuo de revisão e reavaliação de exceções"], "size_estimate": {"approx_tokens":
|
|
3691
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-08-repositorio-de-conformidade-por-aplicacao-controlo-sistematico", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-08"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-08-repositorio-de-conformidade-por-aplicacao-controlo-sistematico", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-08 - Repositório de conformidade por aplicação (controlo sistemático)"], "size_estimate": {"approx_tokens":
|
|
3692
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-09-designacao-formal-de-owners-de-seguranca-por-aplicacao", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-09"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-09-designacao-formal-de-owners-de-seguranca-por-aplicacao", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-09 - Designação formal de owners de segurança por aplicação"], "size_estimate": {"approx_tokens":
|
|
3693
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-10-validacao-periodica-de-aplicacoes-ciclo-de-conformidade", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-10"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-10-validacao-periodica-de-aplicacoes-ciclo-de-conformidade", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-10 - Validação periódica de aplicações (ciclo de conformidade)"], "size_estimate": {"approx_tokens":
|
|
3694
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-11-consolidacao-de-kpis-de-governacao-e-maturidade", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-11"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-11-consolidacao-de-kpis-de-governacao-e-maturidade", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-11 - Consolidação de KPIs de governação e maturidade"], "size_estimate": {"approx_tokens":
|
|
3695
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-12-formalizacao-de-modelo-de-governacao-por-nivel-de-risco", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-12"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-12-formalizacao-de-modelo-de-governacao-por-nivel-de-risco", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-12 - Formalização de modelo de governação por nível de risco"], "size_estimate": {"approx_tokens":
|
|
3696
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-13-controlo-sistematico-e-periodico-por-capitulo-sbd-toe", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-13"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-13-controlo-sistematico-e-periodico-por-capitulo-sbd-toe", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-13 - Controlo sistemático e periódico por capítulo SbD-ToE"], "size_estimate": {"approx_tokens":
|
|
3697
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-14-reavaliacao-continua-e-rotacao-de-fornecedores-pos-onboarding", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-14"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-14-reavaliacao-continua-e-rotacao-de-fornecedores-pos-onboarding", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-14 - Reavaliação contínua e rotação de fornecedores pós-onboarding"], "size_estimate": {"approx_tokens":
|
|
3698
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-15-preparacao-tecnica-e-validacao-de-contractors-pre-acesso", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": ["governance-and-procurement"], "phase": ["govern"], "risk_level": ["L2", "L3"]}, "mentioned_entities": {"Requirement": ["GOV-013"], "UserStory": ["US-06", "US-15"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-15-preparacao-tecnica-e-validacao-de-contractors-pre-acesso", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-15 - Preparação Técnica e Validação de Contractors pré-Acesso"], "size_estimate": {"approx_tokens":
|
|
3699
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-16-trilho-de-formacao-obrigatoria-pre-acesso-contractors", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": ["governance-and-procurement"], "phase": ["govern"], "risk_level": ["L2", "L3"]}, "mentioned_entities": {"Requirement": ["GOV-013"], "UserStory": ["US-06", "US-09", "US-15", "US-16"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-16-trilho-de-formacao-obrigatoria-pre-acesso-contractors", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-16 - Trilho de Formação Obrigatória pré-Acesso (Contractors)"], "size_estimate": {"approx_tokens":
|
|
3700
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-17-offboarding-seguro-de-contractors-e-rescisao-de-fornecedores", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-14", "US-15", "US-17"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-17-offboarding-seguro-de-contractors-e-rescisao-de-fornecedores", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-17 - Offboarding Seguro de Contractors e Rescisão de Fornecedores"], "size_estimate": {"approx_tokens":
|
|
3701
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-18-monitorizacao-continua-de-conformidade-de-fornecedores-alertas-e-escalacao", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-14", "US-18"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-18-monitorizacao-continua-de-conformidade-de-fornecedores-alertas-e-escalacao", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-18 - Monitorização Contínua de Conformidade de Fornecedores (Alertas e Escalação)"], "size_estimate": {"approx_tokens":
|
|
3702
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-19-revisao-trimestral-de-acesso-de-contractors-least-privilege", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": ["governance-and-procurement"], "phase": ["govern"], "risk_level": ["L1", "L2", "L3"]}, "mentioned_entities": {"Requirement": ["GOV-014"], "UserStory": ["US-15", "US-17", "US-19"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-19-revisao-trimestral-de-acesso-de-contractors-least-privilege", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-19 - Revisão Trimestral de Acesso de Contractors (Least Privilege)"], "size_estimate": {"approx_tokens":
|
|
3703
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-20-feedback-pos-projeto-e-rating-de-contractors", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-09", "US-14", "US-17", "US-20"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-20-feedback-pos-projeto-e-rating-de-contractors", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-20 - Feedback Pós-Projeto e Rating de Contractors"], "size_estimate": {"approx_tokens":
|
|
3704
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-21-contratacao-de-provedores-de-modelos-ai-us-21", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": ["dependencies-sbom-sca"], "phase": ["govern"], "risk_level": ["L2", "L3"]}, "mentioned_entities": {"Requirement": ["DEP-014"], "UserStory": ["US-14", "US-21"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-21-contratacao-de-provedores-de-modelos-ai-us-21", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-21 - Contratação de provedores de modelos AI {#us-21}"], "size_estimate": {"approx_tokens": 1326, "chars": 5303}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-21 - Contratação de provedores de modelos AI {#us-21}\n\n**Contexto.**\nA US-14 cobre reavaliação contínua de fornecedores em geral. Quando o fornecedor é um **provedor de modelos AI** (Anthropic, OpenAI, Google, Mistral, Cohere, HuggingFace, providers próprios *self-hosted*), surgem cláusulas que os contratos tradicionais não cobriam: *data retention*, *training opt-out*, localização de processamento (RGPD), audit rights sobre logs de inferência, SLA de notificação de mudanças de versão, conformidade declarada com AI Act Art. 53/55 quando o provedor fornece GPAI. Esta US operacionaliza esses requisitos contratuais antes de o provedor entrar na lista aprovada (cross-link [`DEP-014`](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/catalogo-requisitos-dependencias#dep-014)).\n\n:::userstory\n**História.**\nComo **GRC / Compliance (Procurement + Legal)**, quero que cada contrato com provedor de modelos AI inclua cláusulas mínimas que cubram tratamento de dados, localização, *audit rights*, notificação de mudanças e conformidade regulatória aplicável, para que o uso operacional do provedor seja sustentável jurídica e tecnicamente.\n\n**Critérios de aceitação (BDD).**\n- **Dado** que se pretende adoptar um novo provedor AI para uso operacional\n **Quando** se iniciam as diligências contratuais\n **Então** a *due diligence* (cross-link Policy 33 §3) é estendida com os critérios específicos AI: data retention, training opt-out, localização (RGPD Art. 44–49), audit rights, SLA de notificação, AI Act Art. 53/55 quando GPAI\n- **Dado** que o contrato é finalizado\n **Quando** o provedor é adicionado à lista aprovada ([`DEP-014`](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/catalogo-requisitos-dependencias#dep-014))\n **Então** o `contract_ref` referencia o contrato vigente e regista cláusulas críticas\n- **Dado** que o provedor altera modelo de dados (e.g. nova política de training) ou versão maior do modelo\n **Quando** é notificado conforme SLA contratual\n **Então** corre revisão (`appsec` + `grc`) antes do *cutover*; sem notificação adequada, dispara revisão proactiva\n\n**Checklist.**\n- [ ] *Data retention*: declarada (preferência zero retention para dados sensíveis); compatível com a classificação de dados que o sistema envia\n- [ ] *Training opt-out*: contratualizado quando aplicável; declarado quando \"opt-out por defeito\"\n- [ ] **Localização de processamento**: documentada; conforme RGPD Art. 44–49 quando há dados pessoais; cláusulas para *international transfers* quando aplicável\n- [ ] **Audit rights**: acesso contratualizado a logs de inferência ou equivalente quando exigido (típico em L3)\n- [ ] **SLA de notificação prévia** de mudanças que alterem comportamento (versão maior do modelo, política de dados, descontinuação)\n- [ ] **SLA de disponibilidade** declarado; *fallback* arquitectónico em caso de *outage* (cross-link Cap. 04 §AI/ML)\n- [ ] **Conformidade declarada com AI Act Art. 53/55** quando o provedor fornece GPAI\n- [ ] **Conformidade declarada com RGPD Art. 28** (sub-processadores) quando há dados pessoais\n- [ ] Provedor incluído na lista aprovada ([`DEP-014`](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/catalogo-requisitos-dependencias#dep-014)) com `risk_classification`\n- [ ] Cláusulas críticas registadas na ficha do provedor; revisão calendarizada\n\n:::\n\n**🧾 Artefactos & evidências.**\n- Contrato assinado com cláusulas explícitas (referenciado em `contract_ref` da lista aprovada)\n- Ficha do provedor no repositório de governança (`governance/ai-providers/<provider>.md`) com cláusulas críticas\n- Registo de notificações recebidas do provedor + acções tomadas\n- Revisão periódica documentada conforme nível de risco\n\n**⚖️ Proporcionalidade.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Recomendado | Cláusulas mínimas: localização + zero retention para dados sensíveis |\n| L2 | Sim | Cláusulas detalhadas: retention, opt-out, localização, SLA, audit rights básico |\n| L3 | Sim | Cláusulas detalhadas + audit rights operacionais + AI Act Art. 53/55 quando GPAI; revisão Legal obrigatória |\n\n**🔗 Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Pré-onboarding | Adopção de novo provedor AI | GRC / Compliance (Procurement + Legal) | Antes do uso operacional |\n| Operação | Notificação de mudança pelo provedor | AppSec Engineer + GRC / Compliance | Conforme SLA contratual; pré-*cutover* |\n| Revisão periódica | Cadência por nível de risco | GRC / Compliance | L1 anual / L2 semestral / L3 trimestral |\n| Descontinuação | Provider removido da lista | GRC / Compliance + DevOps / SRE | Plano de migração antes da remoção operacional |\n\n**Ligações úteis.**\n- 🔗 [`DEP-014` — Lista de providers AI aprovados](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/catalogo-requisitos-dependencias#dep-014)\n- 🔗 [US-14 do Cap. 05 — AI BOM](/sbd-toe/sbd-manual/dependencias-sbom-sca/aplicacao-lifecycle)\n- 🔗 [Policy 33 — Contratação Segura (anexo AI providers)](/sbd-toe/assets/policies/policy-contratacao-segura)\n- 🔗 [Policy 39 — AI BOM e Supply Chain](/sbd-toe/assets/policies/policy-ai-bom-supply-chain)\n- 🔗 [Cross-check AI Act](/sbd-toe/cross-check-normativo/ai-act/intro)\n- 🔗 [Cross-check RGPD](/sbd-toe/cross-check-normativo/gdpr/intro)\n\n---", "title": "US-21 - Contratação de provedores de modelos AI {#us-21}", "traceability": {"line_end": 882, "line_start": 818, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-21-contratacao-de-provedores-de-modelos-ai-us-21"}, "vector_text": "US-21 - Contratação de provedores de modelos AI {#us-21}\n\n### US-21 - Contratação de provedores de modelos AI {#us-21}\n\n**Contexto.**\nA US-14 cobre reavaliação contínua de fornecedores em geral. Quando o fornecedor é um **provedor de modelos AI** (Anthropic, OpenAI, Google, Mistral, Cohere, HuggingFace, providers próprios *self-hosted*), surgem cláusulas que os contratos tradicionais não cobriam: *data retention*, *training opt-out*, localização de processamento (RGPD), audit rights sobre logs de inferência, SLA de notificação de mudanças de versão, conformidade declarada com AI Act Art. 53/55 quando o provedor fornece GPAI. Esta US operacionaliza esses requisitos contratuais antes de o provedor entrar na lista aprovada (cross-link [`DEP-014`](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/catalogo-requisitos-dependencias#dep-014)).\n\n:::userstory\n**História.**\nComo **GRC / Compliance (Procurement + Legal)**, quero que cada contrato com provedor de modelos AI inclua cláusulas mínimas que cubram tratamento de dados, localização, *audit rights*, notificação de mudanças e conformidade regulatória aplicável, para que o uso operacional do provedor seja sustentável jurídica e tecnicamente.\n\n**Critérios de aceitação (BDD).**\n- **Dado** que se pretende adoptar um novo provedor AI para uso operacional\n **Quando** se iniciam as diligências contratuais\n **Então** a *due diligence* (cross-link Policy 33 §3) é estendida com os critérios específicos AI: data retention, training opt-out, localização (RGPD Art. 44–49), audit rights, SLA de notificação, AI Act Art. 53/55 quando GPAI\n- **Dado** que o contrato é finalizado\n **Quando** o provedor é adicionado à lista aprovada ([`DEP-014`](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/catalogo-requisitos-dependencias#dep-014))\n **Então** o `contract_ref` referencia o contrato vigente e regista cláusulas críticas\n- **Dado** que o provedor altera modelo de dados (e.g. nova política de training) ou versão maior do modelo\n **Quando** é notificado conforme SLA contratual\n **Então** corre revisão (`appsec` + `grc`) antes do *cutover*; sem notificação adequada, dispara revisão proactiva\n\n**Checklist.**\n- [ ] *Data retention*: declarada (preferência zero retention para dados sensíveis); compatível com a classificação de dados que o sistema envia\n- [ ] *Training opt-out*: contratualizado quando aplicável; declarado quando \"opt-out por defeito\"\n- [ ] **Localização de processamento**: documentada; conforme RGPD Art. 44–49 quando há dados pessoais; cláusulas para *international transfers* quando aplicável\n- [ ] **Audit rights**: acesso contratualizado a logs de inferência ou equivalente quando exigido (típico em L3)\n- [ ] **SLA de notificação prévia** de mudanças que alterem comportamento (versão maior do modelo, política de dados, descontinuação)\n- [ ] **SLA de disponibilidade** declarado; *fallback* arquitectónico em caso de *outage* (cross-link Cap. 04 §AI/ML)\n- [ ] **Conformidade declarada com AI Act Art. 53/55** quando o provedor fornece GPAI\n- [ ] **Conformidade declarada com RGPD Art. 28** (sub-processadores) quando há dados pessoais\n- [ ] Provedor incluído na lista aprovada ([`DEP-014`](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/catalogo-requisitos-dependencias#dep-014)) com `risk_classification`\n- [ ] Cláusulas críticas registadas na ficha do provedor; revisão calendarizada\n\n:::\n\n**🧾 Artefactos & evidências.**\n- Contrato assinado com cláusulas explícitas (referenciado em `contract_ref` da lista aprovada)\n- Ficha do provedor no repositório de governança (`governance/ai-providers/<provider>.md`) com cláusulas críticas\n- Registo de notificações recebidas do provedor + acções tomadas\n- Revisão periódica documentada conforme nível de risco\n\n**⚖️ Proporcionalidade.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Recomendado | Cláusulas mínimas: localização + zero retention para dados sensíveis |\n| L2 | Sim | Cláusulas detalhadas: retention, opt-out, localização, SLA, audit rights básico |\n| L3 | Sim | Cláusulas detalhadas + audit rights operacionais + AI Act Art. 53/55 quando GPAI; revisão Legal obrigatória |\n\n**🔗 Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Pré-onboarding | Adopção de novo provedor AI | GRC / Compliance (Procurement + Legal) | Antes do uso operacional |\n| Operação | Notificação de mudança pelo provedor | AppSec Engineer + GRC / Compliance | Conforme SLA contratual; pré-*cutover* |\n| Revisão periódica | Cadência por nível de risco | GRC / Compliance | L1 anual / L2 semestral / L3 trimestral |\n| Descontinuação | Provider removido da lista | GRC / Compliance + DevOps / SRE | Plano de migração antes da remoção operacional |\n\n**Ligações úteis.**\n- 🔗 [`DEP-014` — Lista de providers AI aprovados](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/catalogo-requisitos-dependencias#dep-014)\n- 🔗 [US-14 do Cap. 05 — AI BOM](/sbd-toe/sbd-manual/dependencias-sbom-sca/aplicacao-lifecycle)\n- 🔗 [Policy 33 — Contratação Segura (anexo AI providers)](/sbd-toe/assets/policies/policy-contratacao-segura)\n- 🔗 [Policy 39 — AI BOM e Supply Chain](/sbd-toe/assets/policies/policy-ai-bom-supply-chain)\n- 🔗 [Cross-check AI Act](/sbd-toe/cross-check-normativo/ai-act/intro)\n- 🔗 [Cross-check RGPD](/sbd-toe/cross-check-normativo/gdpr/intro)\n\n---"}
|
|
3705
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-22-aprovacao-formal-e-auditoria-periodica-das-politicas-organizacionais-us-22", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-12", "US-22"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-22-aprovacao-formal-e-auditoria-periodica-das-politicas-organizacionais-us-22", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-22 - Aprovação formal e auditoria periódica das políticas organizacionais {#us-22}"], "size_estimate": {"approx_tokens": 1037, "chars": 4148}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-22 - Aprovação formal e auditoria periódica das políticas organizacionais {#us-22}\n\nUma política não aprovada pela direção não tem autoridade; uma política não auditada perde aderência ao longo do tempo. \n\n**Contexto.** O capítulo prescreve um conjunto de políticas organizacionais relevantes (gestão de exceções, contratação segura, rastreabilidade organizacional, auditoria de fornecedores, KPIs de governação — ver intro §Políticas Organizacionais Relevantes) e o checklist canónico exige que estas estejam *formalmente aprovadas e auditadas*. A US-12 formaliza a política do **modelo de governação**, mas o restante corpo de políticas fica sem uma user story que operacionalize o seu ciclo de aprovação pela direção e de auditoria periódica. Sem este ciclo, as políticas existem como documento mas não como controlo vivo: ninguém confirma que continuam aprovadas, atualizadas e cumpridas. \n\n:::userstory\n**História.** \nComo **GRC / Compliance** com apoio de **CISO + Gestão Executiva**, quero **manter cada política organizacional do capítulo num ciclo formal de aprovação pela direção e de auditoria periódica de aderência**, para **garantir que o corpo de políticas tem autoridade, está atualizado e é efetivamente cumprido e auditável**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** uma política organizacional relevante (exceções, contratação segura, rastreabilidade, auditoria de fornecedores, KPIs de governação) \n **Quando** é criada ou revista \n **Então** é submetida a aprovação formal da direção, com versão, data e aprovador registados antes de entrar em vigor \n- **Dado** uma política em vigor \n **Quando** chega o ciclo de auditoria definido (no máximo anual) \n **Então** é auditada a aderência prática, registam-se desvios e gera-se ação corretiva com owner e prazo \n\n**Checklist.** \n- [ ] Inventário das políticas organizacionais relevantes do capítulo mantido e versionado, com estado (Obrigatória/Recomendado), owner e data da última aprovação \n- [ ] Cada política tem aprovação formal da direção registada (versão, data, aprovador) antes de entrar em vigor; revisão pelo menos anual ou após mudança organizacional significativa \n- [ ] Auditoria periódica de aderência executada por ciclo definido, com desvios registados e ações corretivas (owner + prazo) acompanhadas até fecho \n\n:::\n\n**Artefactos & evidências.** Inventário versionado de políticas com estado e owner; registo de aprovação formal pela direção (versão/data/aprovador); relatório de auditoria de aderência por ciclo; plano de ações corretivas para desvios. \n\n**Proporcionalidade L1–L3.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Políticas obrigatórias aprovadas; auditoria informal anual | Conjunto completo aprovado; auditoria formal anual com registo de desvios | Conjunto completo aprovado; auditoria formal ≤ anual + revisão por mudança organizacional; ações corretivas rastreadas até fecho |\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|------|---------|-------------|-----|\n| Planeamento | Criação ou revisão de política | GRC / Compliance + CISO + Gestão Executiva (aprovação) | Aprovação antes da entrada em vigor |\n| Auditoria | Ciclo periódico (≤ anual) ou mudança organizacional | GRC / Compliance + AppSec Engineer | Auditoria concluída no ciclo; ações corretivas com prazo definido |\n\n**Ligações úteis.** \n- [Checklist de Revisão Periódica — Governança e Contratação](/sbd-toe/sbd-manual/governanca-contratacao/canon/checklist-revisao)\n- [Modelo formal de governação — US-12](#us-12---formalização-de-modelo-de-governação-por-nível-de-risco)\n- [Processo Canónico de Gestão de Exceções](./addon/processo-excecoes)\n- [Política de Gestão de Exceções de Segurança](/sbd-toe/assets/policies/policy-gestao-excecoes)\n- [Política de Contratação Segura](/sbd-toe/assets/policies/policy-contratacao-segura)\n- [Política de Rastreabilidade Organizacional](/sbd-toe/assets/policies/policy-rastreabilidade-organizacional)\n- [Política de KPIs de Governação de Segurança](/sbd-toe/assets/policies/policy-kpis-governacao)\n\n---", "title": "US-22 - Aprovação formal e auditoria periódica das políticas organizacionais {#us-22}", "traceability": {"line_end": 931, "line_start": 883, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-22-aprovacao-formal-e-auditoria-periodica-das-politicas-organizacionais-us-22"}, "vector_text": "US-22 - Aprovação formal e auditoria periódica das políticas organizacionais {#us-22}\n\n### US-22 - Aprovação formal e auditoria periódica das políticas organizacionais {#us-22}\n\nUma política não aprovada pela direção não tem autoridade; uma política não auditada perde aderência ao longo do tempo. \n\n**Contexto.** O capítulo prescreve um conjunto de políticas organizacionais relevantes (gestão de exceções, contratação segura, rastreabilidade organizacional, auditoria de fornecedores, KPIs de governação — ver intro §Políticas Organizacionais Relevantes) e o checklist canónico exige que estas estejam *formalmente aprovadas e auditadas*. A US-12 formaliza a política do **modelo de governação**, mas o restante corpo de políticas fica sem uma user story que operacionalize o seu ciclo de aprovação pela direção e de auditoria periódica. Sem este ciclo, as políticas existem como documento mas não como controlo vivo: ninguém confirma que continuam aprovadas, atualizadas e cumpridas. \n\n:::userstory\n**História.** \nComo **GRC / Compliance** com apoio de **CISO + Gestão Executiva**, quero **manter cada política organizacional do capítulo num ciclo formal de aprovação pela direção e de auditoria periódica de aderência**, para **garantir que o corpo de políticas tem autoridade, está atualizado e é efetivamente cumprido e auditável**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** uma política organizacional relevante (exceções, contratação segura, rastreabilidade, auditoria de fornecedores, KPIs de governação) \n **Quando** é criada ou revista \n **Então** é submetida a aprovação formal da direção, com versão, data e aprovador registados antes de entrar em vigor \n- **Dado** uma política em vigor \n **Quando** chega o ciclo de auditoria definido (no máximo anual) \n **Então** é auditada a aderência prática, registam-se desvios e gera-se ação corretiva com owner e prazo \n\n**Checklist.** \n- [ ] Inventário das políticas organizacionais relevantes do capítulo mantido e versionado, com estado (Obrigatória/Recomendado), owner e data da última aprovação \n- [ ] Cada política tem aprovação formal da direção registada (versão, data, aprovador) antes de entrar em vigor; revisão pelo menos anual ou após mudança organizacional significativa \n- [ ] Auditoria periódica de aderência executada por ciclo definido, com desvios registados e ações corretivas (owner + prazo) acompanhadas até fecho \n\n:::\n\n**Artefactos & evidências.** Inventário versionado de políticas com estado e owner; registo de aprovação formal pela direção (versão/data/aprovador); relatório de auditoria de aderência por ciclo; plano de ações corretivas para desvios. \n\n**Proporcionalidade L1–L3.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Políticas obrigatórias aprovadas; auditoria informal anual | Conjunto completo aprovado; auditoria formal anual com registo de desvios | Conjunto completo aprovado; auditoria formal ≤ anual + revisão por mudança organizacional; ações corretivas rastreadas até fecho |\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|------|---------|-------------|-----|\n| Planeamento | Criação ou revisão de política | GRC / Compliance + CISO + Gestão Executiva (aprovação) | Aprovação antes da entrada em vigor |\n| Auditoria | Ciclo periódico (≤ anual) ou mudança organizacional | GRC / Compliance + AppSec Engineer | Auditoria concluída no ciclo; ações corretivas com prazo definido |\n\n**Ligações úteis.** \n- [Checklist de Revisão Periódica — Governança e Contratação](/sbd-toe/sbd-manual/governanca-contratacao/canon/checklist-revisao)\n- [Modelo formal de governação — US-12](#us-12---formalização-de-modelo-de-governação-por-nível-de-risco)\n- [Processo Canónico de Gestão de Exceções](./addon/processo-excecoes)\n- [Política de Gestão de Exceções de Segurança](/sbd-toe/assets/policies/policy-gestao-excecoes)\n- [Política de Contratação Segura](/sbd-toe/assets/policies/policy-contratacao-segura)\n- [Política de Rastreabilidade Organizacional](/sbd-toe/assets/policies/policy-rastreabilidade-organizacional)\n- [Política de KPIs de Governação de Segurança](/sbd-toe/assets/policies/policy-kpis-governacao)\n\n---"}
|
|
3706
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--artefactos-esperados", "chunk_kind": "table_section", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "table_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--artefactos-esperados", "relation_hints": [], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📦 Artefactos esperados"], "size_estimate": {"approx_tokens": 322, "chars": 1288}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## 📦 Artefactos esperados\n\n| Artefacto | Evidência |\n|-----------|-----------|\n| Registo de exceções com alçadas | Ferramenta GRC versionada, decisões auditáveis |\n| Contratos com cláusulas | Documentos validados juridicamente |\n| Relatórios de fornecedores | Auditorias e findings, análise técnica |\n| Dashboard organizacional | Métricas por projeto e aplicação |\n| Relatórios KPIs | Consolidação trimestral/semestral |\n| Formulário de validação de fornecedores | Questionário preenchido, Análise AppSec, GRC registo |\n| Tabela de exceções com calendário de revalidação | Rastreabilidade com datas de vencimento |\n| Repositório de conformidade por app | Ficheiro YAML/MD versionado, Histórico auditável |\n| Documento de designação de owners | Registo centralizado com formação validada |\n| Relatórios de validação periódica | Checklist + Plano de acção, histórico ciclos |\n| Dashboard de KPIs e maturidade | Métricas por capítulo, Tendências históricas |\n| Política de Governação SbD-ToE | Documento aprovado, Níveis de alçada, Template de decisão |\n| Checklist de conformidade centralizado | Ficheiro versionado por app (YAML/MD), Git history |\n| Calendário de reavaliação de fornecedores | Planeamento trimestral/semestral/anual, Notificações automáticas |\n\n---", "title": "📦 Artefactos esperados", "traceability": {"line_end":
|
|
3707
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-proporcionalidade-l1l3", "chunk_kind": "table_section", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "table_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-proporcionalidade-l1l3", "relation_hints": [], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "⚖️ Matriz de proporcionalidade L1–L3"], "size_estimate": {"approx_tokens": 428, "chars": 1711}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## ⚖️ Matriz de proporcionalidade L1–L3\n\n| Prática | L1 | L2 | L3 |\n|---------|----|----|----|\n| Exceções formais com alçadas | Opcional | Recomendado | Obrigatório |\n| Cláusulas contratuais | Recomendado | Obrigatório | Obrigatório + auditorias |\n| Validação de fornecedores (inicial) | Opcional | Recomendado | Obrigatório |\n| Rastreabilidade organizacional | Básico | Recomendado | Obrigatório |\n| KPIs de governação | Básico | Recomendado | Obrigatório |\n| Fluxo formal de validação fornecedores | Opcional | Recomendado | Obrigatório |\n| Revisão contínua de exceções | Básico | Recomendado | Obrigatório |\n| Repositório de conformidade por app | Básico | Recomendado | Obrigatório |\n| Designação formal de owners de segurança | Recomendado | Obrigatório | Obrigatório |\n| Validação periódica de conformidade | Anual | Semestral | Trimestral |\n| KPIs de maturidade e reporta executiva | Básico | Recomendado | Obrigatório |\n| Modelo formal de governação | Básico | Recomendado | Obrigatório |\n| Checklist centralizado por capítulo | Básico | Recomendado | Obrigatório |\n| Reavaliação de fornecedores pós-onboarding | Anual | Semestral | Trimestral / evento crítico |\n| **Preparação técnica de contractors** | Básico | Recomendado | Obrigatório + quiz validado |\n| **Trilho de formação pré-acesso** | Básico | Obrigatório | Obrigatório + 80% score |\n| **Offboarding seguro** | Básico | Obrigatório | Obrigatório + audit trail |\n| **Monitorização contínua de fornecedores** | Não | Recomendado | Obrigatório |\n| **Revisão trimestral de acesso (contractors)** | Semestral | Trimestral | Trimestral |\n| **Feedback pós-projeto** | Opcional | Recomendado | Obrigatório |\n\n---", "title": "⚖️ Matriz de proporcionalidade L1–L3", "traceability": {"line_end":
|
|
3708
|
-
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--recomendacoes-finais", "chunk_kind": "checklist_section", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "checklist_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-01", "US-02", "US-04", "US-05", "US-06", "US-07", "US-08", "US-09", "US-10", "US-11", "US-12", "US-13", "US-14", "US-15", "US-16", "US-17", "US-18", "US-19", "US-20"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--recomendacoes-finais", "relation_hints": [], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "🏁 Recomendações finais"], "size_estimate": {"approx_tokens": 546, "chars": 2183}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## 🏁 Recomendações finais\n\n- **Exceções sem registo = risco invisível.** Operacionalize US-01 (com alçadas claras) e US-07 para garantir rastreabilidade contínua e revalidação automática. \n- **Modelo formal é o alicerce.** US-12 documenta governação com critérios explícitos, alçadas por L1–L3, e formação obrigatória para approvers (Cap. 13). \n- **Fornecedores devem ser parte do modelo SbD-ToE.** Use US-02, US-06, US-14, e US-18 para integração contratual, validação inicial, reavaliação periódica, e monitorização contínua. \n- **Contractors merecem ciclo de vida dedicado.** US-15 (preparação técnica), US-16 (formação obrigatória), US-17 (offboarding) e US-19 (revisão de acesso) garantem que contractors são preparados, mantêm least privilege, e saem seguramente. \n- **Designação clara de owners elimina responsabilidade dispersa.** US-09 garante continuidade de decisões de segurança com formação validada. \n- **Repositório centralizado de conformidade dá visibilidade total.** US-08 e US-13 consolidam estado de todas as práticas por aplicação, capítulo e ciclo. \n- **Validações periódicas detetam desvios cedo.** US-10 integra revisão contínua no ciclo de vida; US-13 valida por capítulo; US-14 reavalia fornecedores; US-19 valida acesso de contractors. \n- **KPIs de governação são a medida objetiva da maturidade.** US-05 e US-11 permitem decisão estratégica baseada em evidência (% conformidade, % exceções resolvidas, % fornecedores auditados). \n- **Rastreabilidade organizacional dá transparência à gestão.** US-04 agregada com US-08, US-10, US-13, US-14, US-20 cria visibilidade de risco em todos os níveis. \n- **Preparação e feedback contínuos melhoram qualidade de contractors.** US-15, US-16, US-20 criam ciclo de melhoria contínua e base de dados de avaliação para re-hire. \n- **Este capítulo é o \"cimento\" que une os restantes 2–13:** torna práticas visíveis, auditáveis, rastreáveis e sustentáveis ao longo do tempo. Sem governação formal (US-12), controlo sistemático (US-13), ciclo de vida de contractors (US-15–17, 19–20), e reavaliação contínua (US-01, US-07, US-14, US-18), o SbD-ToE fica limitado à prática técnica pontual.", "title": "🏁 Recomendações finais", "traceability": {"line_end":
|
|
3683
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-01-processo-formal-de-excecoes-com-alcadas-por-nivel-de-risco", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-01"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-01-processo-formal-de-excecoes-com-alcadas-por-nivel-de-risco", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📖 User Stories normalizadas", "US-01 - Processo formal de exceções com alçadas por nível de risco"], "size_estimate": {"approx_tokens": 553, "chars": 2210}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-01 - Processo formal de exceções com alçadas por nível de risco\n**Contexto.** Sem exceções formais, práticas são ignoradas sem transparência. Sem alçadas claras por nível de risco, decisões são inconsistentes e responsabilidade dispersa. \n\n:::userstory\n**História.** \nComo **Developer + AppSec Engineer**, quero **submeter exceções de segurança em fluxo formal com roteamento automático por nível de risco (L1→gestor app, L2→AppSec+gestor, L3→CISO+AppSec+direção)**, para **assegurar transparência, aprovação proporcional ao risco, e revalidação periódica**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** que um controlo não pode ser cumprido numa aplicação classificada como L1, L2 ou L3 \n **Quando** submeto exceção com justificação técnica e compensação \n **Então** ela é roteada para alçada apropriada, avaliada, e aprovada ou rejeitada \n- E um calendário de revalidação é automaticamente criado (L3: 3 meses, L2: 6 meses, L1: anual) \n\n**Critérios de aceitação (DoD).** \n- [ ] Exceção registada em ferramenta GRC com campos obrigatórios: aplicação, risco (L1–L3), controlo em falta, justificação, compensação, owner \n- [ ] Alçada de aprovação determinada automaticamente por nível de risco \n- [ ] Aprovação formal recebida (assinatura digital ou registo de timestamp) \n- [ ] Calendário de revalidação criado e owner notificado (30 dias antes de expiração) \n- [ ] Issue de mitigação criada no backlog de segurança para próxima release \n- [ ] Notificação automática enviada a owner se exceção se aproxima de vencer \n\n:::\n\n**Artefactos & evidências.** Registo exceções versionado, Decisão formalizada com alçada, Calendário de revalidação, Issue no backlog, Notificações automáticas \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Opcional | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Execução | Sempre que há desvio | Developer (submissão) + AppSec Engineer (validação) + Gestão Executiva / CISO (aprovação conforme nível) | Aprovação em 5 dias (L1–L2), 3 dias (L3); Notificação de revalidação 30 dias antes do vencimento |\n\n---", "title": "US-01 - Processo formal de exceções com alçadas por nível de risco", "traceability": {"line_end": 74, "line_start": 38, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-01-processo-formal-de-excecoes-com-alcadas-por-nivel-de-risco"}, "vector_text": "US-01 - Processo formal de exceções com alçadas por nível de risco\n\n### US-01 - Processo formal de exceções com alçadas por nível de risco\n**Contexto.** Sem exceções formais, práticas são ignoradas sem transparência. Sem alçadas claras por nível de risco, decisões são inconsistentes e responsabilidade dispersa. \n\n:::userstory\n**História.** \nComo **Developer + AppSec Engineer**, quero **submeter exceções de segurança em fluxo formal com roteamento automático por nível de risco (L1→gestor app, L2→AppSec+gestor, L3→CISO+AppSec+direção)**, para **assegurar transparência, aprovação proporcional ao risco, e revalidação periódica**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** que um controlo não pode ser cumprido numa aplicação classificada como L1, L2 ou L3 \n **Quando** submeto exceção com justificação técnica e compensação \n **Então** ela é roteada para alçada apropriada, avaliada, e aprovada ou rejeitada \n- E um calendário de revalidação é automaticamente criado (L3: 3 meses, L2: 6 meses, L1: anual) \n\n**Critérios de aceitação (DoD).** \n- [ ] Exceção registada em ferramenta GRC com campos obrigatórios: aplicação, risco (L1–L3), controlo em falta, justificação, compensação, owner \n- [ ] Alçada de aprovação determinada automaticamente por nível de risco \n- [ ] Aprovação formal recebida (assinatura digital ou registo de timestamp) \n- [ ] Calendário de revalidação criado e owner notificado (30 dias antes de expiração) \n- [ ] Issue de mitigação criada no backlog de segurança para próxima release \n- [ ] Notificação automática enviada a owner se exceção se aproxima de vencer \n\n:::\n\n**Artefactos & evidências.** Registo exceções versionado, Decisão formalizada com alçada, Calendário de revalidação, Issue no backlog, Notificações automáticas \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Opcional | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Execução | Sempre que há desvio | Developer (submissão) + AppSec Engineer (validação) + Gestão Executiva / CISO (aprovação conforme nível) | Aprovação em 5 dias (L1–L2), 3 dias (L3); Notificação de revalidação 30 dias antes do vencimento |\n\n---"}
|
|
3684
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-02-clausulas-contratuais-de-seguranca", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-02"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-02-clausulas-contratuais-de-seguranca", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📖 User Stories normalizadas", "US-02 - Cláusulas contratuais de segurança"], "size_estimate": {"approx_tokens": 263, "chars": 1051}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-02 - Cláusulas contratuais de segurança\n**Contexto.** Fornecedores sem cláusulas podem comprometer toda a cadeia. \n\n:::userstory\n**História.** \nComo **GRC / Compliance (Jurídico + Procurement)**, quero **incluir cláusulas SbD-ToE em contratos**, para **garantir conformidade de fornecedores**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** contrato novo \n **Quando** cláusulas são aplicadas \n **Então** fornecedor compromete-se a cumprir práticas de segurança \n\n**Critérios de aceitação (DoD).** \n- [ ] Cláusulas publicadas em modelo contratual \n- [ ] Contratos validados juridicamente \n- [ ] Monitorização de conformidade \n\n:::\n\n**Artefactos & evidências.** Contratos, cláusulas \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Recomendado | Obrigatório | Obrigatório + auditorias |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Planeamento | Contrato novo | GRC / Compliance (Jurídico + Procurement) | Conforme ciclo da US |\n\n---", "title": "US-02 - Cláusulas contratuais de segurança", "traceability": {"line_end": 107, "line_start": 75, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-02-clausulas-contratuais-de-seguranca"}, "vector_text": "US-02 - Cláusulas contratuais de segurança\n\n### US-02 - Cláusulas contratuais de segurança\n**Contexto.** Fornecedores sem cláusulas podem comprometer toda a cadeia. \n\n:::userstory\n**História.** \nComo **GRC / Compliance (Jurídico + Procurement)**, quero **incluir cláusulas SbD-ToE em contratos**, para **garantir conformidade de fornecedores**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** contrato novo \n **Quando** cláusulas são aplicadas \n **Então** fornecedor compromete-se a cumprir práticas de segurança \n\n**Critérios de aceitação (DoD).** \n- [ ] Cláusulas publicadas em modelo contratual \n- [ ] Contratos validados juridicamente \n- [ ] Monitorização de conformidade \n\n:::\n\n**Artefactos & evidências.** Contratos, cláusulas \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Recomendado | Obrigatório | Obrigatório + auditorias |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Planeamento | Contrato novo | GRC / Compliance (Jurídico + Procurement) | Conforme ciclo da US |\n\n---"}
|
|
3685
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-03-validacao-continua-de-fornecedores", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-03"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-03-validacao-continua-de-fornecedores", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📖 User Stories normalizadas", "US-03 - Validação contínua de fornecedores"], "size_estimate": {"approx_tokens": 228, "chars": 910}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-03 - Validação contínua de fornecedores\n**Contexto.** Fornecedores comprometidos propagam risco. \n\n:::userstory\n**História.** \nComo **GRC / Compliance**, quero **validar fornecedores de forma contínua**, para **assegurar conformidade e segurança contratual**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** fornecedor ativo \n **Quando** auditoria ocorre \n **Então** relatório documenta conformidade \n\n**Critérios de aceitação (DoD).** \n- [ ] Auditoria anual \n- [ ] Relatório publicado \n- [ ] Findings registados \n\n:::\n\n**Artefactos & evidências.** Relatórios de auditoria \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Opcional | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Validação | Auditoria de fornecedor ativo | GRC / Compliance | Auditoria anual |\n\n---", "title": "US-03 - Validação contínua de fornecedores", "traceability": {"line_end": 140, "line_start": 108, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-03-validacao-continua-de-fornecedores"}, "vector_text": "US-03 - Validação contínua de fornecedores\n\n### US-03 - Validação contínua de fornecedores\n**Contexto.** Fornecedores comprometidos propagam risco. \n\n:::userstory\n**História.** \nComo **GRC / Compliance**, quero **validar fornecedores de forma contínua**, para **assegurar conformidade e segurança contratual**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** fornecedor ativo \n **Quando** auditoria ocorre \n **Então** relatório documenta conformidade \n\n**Critérios de aceitação (DoD).** \n- [ ] Auditoria anual \n- [ ] Relatório publicado \n- [ ] Findings registados \n\n:::\n\n**Artefactos & evidências.** Relatórios de auditoria \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Opcional | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Validação | Auditoria de fornecedor ativo | GRC / Compliance | Auditoria anual |\n\n---"}
|
|
3686
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-04-rastreabilidade-organizacional", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-04"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-04-rastreabilidade-organizacional", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📖 User Stories normalizadas", "US-04 - Rastreabilidade organizacional"], "size_estimate": {"approx_tokens": 249, "chars": 993}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-04 - Rastreabilidade organizacional\n**Contexto.** Sem rastreabilidade, a gestão não tem visibilidade real. \n\n:::userstory\n**História.** \nComo **AppSec Engineer**, quero **agregar práticas de segurança por projeto em dashboard organizacional**, para **dar visibilidade e medir adoção**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** projetos ativos \n **Quando** métricas são recolhidas \n **Então** dashboard mostra estado global \n\n**Critérios de aceitação (DoD).** \n- [ ] Dashboard configurado \n- [ ] Métricas por capítulo recolhidas \n- [ ] Relatórios entregues à direção \n\n:::\n\n**Artefactos & evidências.** Dashboard, relatórios \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Operação | Recolha de métricas de projetos ativos | AppSec Engineer + GRC / Compliance | Conforme ciclo da US |\n\n---", "title": "US-04 - Rastreabilidade organizacional", "traceability": {"line_end": 173, "line_start": 141, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--user-stories-normalizadas--us-04-rastreabilidade-organizacional"}, "vector_text": "US-04 - Rastreabilidade organizacional\n\n### US-04 - Rastreabilidade organizacional\n**Contexto.** Sem rastreabilidade, a gestão não tem visibilidade real. \n\n:::userstory\n**História.** \nComo **AppSec Engineer**, quero **agregar práticas de segurança por projeto em dashboard organizacional**, para **dar visibilidade e medir adoção**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** projetos ativos \n **Quando** métricas são recolhidas \n **Então** dashboard mostra estado global \n\n**Critérios de aceitação (DoD).** \n- [ ] Dashboard configurado \n- [ ] Métricas por capítulo recolhidas \n- [ ] Relatórios entregues à direção \n\n:::\n\n**Artefactos & evidências.** Dashboard, relatórios \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Operação | Recolha de métricas de projetos ativos | AppSec Engineer + GRC / Compliance | Conforme ciclo da US |\n\n---"}
|
|
3687
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global", "chunk_kind": "checklist_section", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "checklist_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-01", "US-02", "US-03", "US-04", "US-06", "US-07"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global", "relation_hints": [], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global"], "size_estimate": {"approx_tokens": 377, "chars": 1507}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## 📊 Matriz de Rastreabilidade Global\n\nA tabela seguinte consolida as práticas de rastreabilidade aplicadas em cada capítulo, mostrando o ponto focal para auditoria e governação:\n\n| Capítulo | US | Contexto | Artefacto principal | Responsável |\n|----------|----|---------|--------------------|-------------|\n| **Cap 02** | US-07 | Requisitos com tags `SEC-Lx-*` | Backlog com rastreabilidade | QA / Product Owner |\n| **Cap 07** | US-03 | Logs e correlação commit-build-release | Relatórios CI/CD + audit trail | DevOps / SRE |\n| **Cap 08** | US-02 | Módulos versionados e rastreáveis | Histórico de módulos IaC | DevOps / SRE |\n| **Cap 09** | US-06 | SBOM com proveniência por imagem | `sbom.json` + metadados | DevOps / SRE |\n| **Cap 11** | US-02 | Rastreabilidade ponta-a-ponta (build → deploy → runtime) | Attestations + logs de deploy | DevOps / SRE |\n| **Cap 12** | US-01 | Eventos de segurança correlacionados | Eventos + logs SIEM | Operações (Ops) / AppSec Engineer |\n| **Cap 14** | US-04 | Dashboard organizacional de métricas | Dashboard + relatórios trimestrais | AppSec Engineer + GRC / Compliance |\n\n**Notas:**\n- Cada capítulo tem **um ponto focal de rastreabilidade** que se integra na matriz organizacional\n- **Cap 14 - US-04** agrega dados de todos os capítulos para visibilidade executiva\n- Todos os artefactos devem ser **versionados** e **auditáveis** conforme nível L1–L3\n- **SLA mínimo:** Relatórios mensais (L1), quinzenais (L2), contínuos (L3)\n\n---", "title": "📊 Matriz de Rastreabilidade Global", "traceability": {"line_end": 195, "line_start": 174, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global"}, "vector_text": "📊 Matriz de Rastreabilidade Global\n\n## 📊 Matriz de Rastreabilidade Global\n\nA tabela seguinte consolida as práticas de rastreabilidade aplicadas em cada capítulo, mostrando o ponto focal para auditoria e governação:\n\n| Capítulo | US | Contexto | Artefacto principal | Responsável |\n|----------|----|---------|--------------------|-------------|\n| **Cap 02** | US-07 | Requisitos com tags `SEC-Lx-*` | Backlog com rastreabilidade | QA / Product Owner |\n| **Cap 07** | US-03 | Logs e correlação commit-build-release | Relatórios CI/CD + audit trail | DevOps / SRE |\n| **Cap 08** | US-02 | Módulos versionados e rastreáveis | Histórico de módulos IaC | DevOps / SRE |\n| **Cap 09** | US-06 | SBOM com proveniência por imagem | `sbom.json` + metadados | DevOps / SRE |\n| **Cap 11** | US-02 | Rastreabilidade ponta-a-ponta (build → deploy → runtime) | Attestations + logs de deploy | DevOps / SRE |\n| **Cap 12** | US-01 | Eventos de segurança correlacionados | Eventos + logs SIEM | Operações (Ops) / AppSec Engineer |\n| **Cap 14** | US-04 | Dashboard organizacional de métricas | Dashboard + relatórios trimestrais | AppSec Engineer + GRC / Compliance |\n\n**Notas:**\n- Cada capítulo tem **um ponto focal de rastreabilidade** que se integra na matriz organizacional\n- **Cap 14 - US-04** agrega dados de todos os capítulos para visibilidade executiva\n- Todos os artefactos devem ser **versionados** e **auditáveis** conforme nível L1–L3\n- **SLA mínimo:** Relatórios mensais (L1), quinzenais (L2), contínuos (L3)\n\n---"}
|
|
3688
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-05-kpis-de-governacao", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-05"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-05-kpis-de-governacao", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-05 - KPIs de governação"], "size_estimate": {"approx_tokens": 233, "chars": 930}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-05 - KPIs de governação\n**Contexto.** Sem métricas, não há melhoria contínua. \n\n:::userstory\n**História.** \nComo **Gestão Executiva**, quero **definir e monitorizar KPIs de governação**, para **avaliar eficácia do programa SbD-ToE**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** ciclo trimestral \n **Quando** KPIs são medidos \n **Então** relatório é partilhado com direção \n\n**Critérios de aceitação (DoD).** \n- [ ] KPIs definidos (ex.: exceções, fornecedores auditados) \n- [ ] Métricas recolhidas \n- [ ] Relatório partilhado \n\n:::\n\n**Artefactos & evidências.** Relatórios KPIs \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Auditoria | Ciclo trimestral de medição de KPIs | Gestão Executiva + GRC / Compliance | Conforme ciclo da US |\n\n---", "title": "US-05 - KPIs de governação", "traceability": {"line_end": 228, "line_start": 196, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-05-kpis-de-governacao"}, "vector_text": "US-05 - KPIs de governação\n\n### US-05 - KPIs de governação\n**Contexto.** Sem métricas, não há melhoria contínua. \n\n:::userstory\n**História.** \nComo **Gestão Executiva**, quero **definir e monitorizar KPIs de governação**, para **avaliar eficácia do programa SbD-ToE**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** ciclo trimestral \n **Quando** KPIs são medidos \n **Então** relatório é partilhado com direção \n\n**Critérios de aceitação (DoD).** \n- [ ] KPIs definidos (ex.: exceções, fornecedores auditados) \n- [ ] Métricas recolhidas \n- [ ] Relatório partilhado \n\n:::\n\n**Artefactos & evidências.** Relatórios KPIs \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Auditoria | Ciclo trimestral de medição de KPIs | Gestão Executiva + GRC / Compliance | Conforme ciclo da US |\n\n---"}
|
|
3689
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-06-execucao-de-fluxo-formal-de-validacao-de-fornecedores", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-06"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-06-execucao-de-fluxo-formal-de-validacao-de-fornecedores", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-06 - Execução de fluxo formal de validação de fornecedores"], "size_estimate": {"approx_tokens": 416, "chars": 1662}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-06 - Execução de fluxo formal de validação de fornecedores\n**Contexto.** Fornecedores não validados introduzem risco não rastreável na cadeia de suprimentos. \n\n:::userstory\n**História.** \nComo **GRC / Compliance (Procurement Officer)**, quero **executar o fluxo formal de validação de fornecedores (questionário → análise AppSec → aprovação)**, para **garantir que novos fornecedores cumprem requisitos mínimos antes do onboarding**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** um novo fornecedor classificado como L2 ou L3 \n **Quando** o fluxo de validação é iniciado \n **Então** questionário é enviado, analisado por AppSec, e aprovação/exceção é registada \n\n**Critérios de aceitação (DoD).** \n- [ ] Checklist de validação preenchido (questionário, cláusulas, evidência) \n- [ ] Análise técnica por AppSec Engineer documentada \n- [ ] Decisão formalizada (Aprovação / Rejeição / Exceção) registada em GRC \n- [ ] Owner de Fornecedor designado e notificado \n\n:::\n\n**Artefactos & evidências.** Formulário de questionário, Relatório de análise AppSec, Registo GRC \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Opcional | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Planeamento | Novo fornecedor L2/L3; início do fluxo de validação | AppSec Engineer + GRC / Compliance (Procurement Officer) | 2 semanas (L2), 1 semana (L3) |\n\n**Ligações úteis.** \n- [Modelo de Validação de Fornecedores](./addon/modelo-validacao-fornecedores)\n- [Exemplos Práticos](./addon/exemplos-aplicacao-governanca)\n\n---", "title": "US-06 - Execução de fluxo formal de validação de fornecedores", "traceability": {"line_end": 266, "line_start": 229, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-06-execucao-de-fluxo-formal-de-validacao-de-fornecedores"}, "vector_text": "US-06 - Execução de fluxo formal de validação de fornecedores\n\n### US-06 - Execução de fluxo formal de validação de fornecedores\n**Contexto.** Fornecedores não validados introduzem risco não rastreável na cadeia de suprimentos. \n\n:::userstory\n**História.** \nComo **GRC / Compliance (Procurement Officer)**, quero **executar o fluxo formal de validação de fornecedores (questionário → análise AppSec → aprovação)**, para **garantir que novos fornecedores cumprem requisitos mínimos antes do onboarding**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** um novo fornecedor classificado como L2 ou L3 \n **Quando** o fluxo de validação é iniciado \n **Então** questionário é enviado, analisado por AppSec, e aprovação/exceção é registada \n\n**Critérios de aceitação (DoD).** \n- [ ] Checklist de validação preenchido (questionário, cláusulas, evidência) \n- [ ] Análise técnica por AppSec Engineer documentada \n- [ ] Decisão formalizada (Aprovação / Rejeição / Exceção) registada em GRC \n- [ ] Owner de Fornecedor designado e notificado \n\n:::\n\n**Artefactos & evidências.** Formulário de questionário, Relatório de análise AppSec, Registo GRC \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Opcional | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Planeamento | Novo fornecedor L2/L3; início do fluxo de validação | AppSec Engineer + GRC / Compliance (Procurement Officer) | 2 semanas (L2), 1 semana (L3) |\n\n**Ligações úteis.** \n- [Modelo de Validação de Fornecedores](./addon/modelo-validacao-fornecedores)\n- [Exemplos Práticos](./addon/exemplos-aplicacao-governanca)\n\n---"}
|
|
3690
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-07-ciclo-continuo-de-revisao-e-reavaliacao-de-excecoes", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-07"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-07-ciclo-continuo-de-revisao-e-reavaliacao-de-excecoes", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-07 - Ciclo contínuo de revisão e reavaliação de exceções"], "size_estimate": {"approx_tokens": 419, "chars": 1676}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-07 - Ciclo contínuo de revisão e reavaliação de exceções\n**Contexto.** Exceções esquecidas tornam-se risco permanente não mitigado. \n\n:::userstory\n**História.** \nComo **AppSec Engineer**, quero **revisar e reavaliar exceções e compensações de forma periódica**, para **garantir que o risco residual continua mitigado e que compensações permanecem eficazes**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** uma exceção ou compensação ativa com prazo de revisão \n **Quando** chega a data de revisão agendada (ou ocorre evento crítico) \n **Então** é reavaliada, revalidada, prorrogada ou encerrada \n\n**Critérios de aceitação (DoD).** \n- [ ] Calendário de revisão definido por criticidade (L3 trimestral, L2 semestral) \n- [ ] Registo de exceção atualizado com nova data de revisão \n- [ ] Reavaliação documentada (mantém-se, prolonga-se, encerra-se) \n- [ ] Owner de Segurança notificado e decisão aprovada \n\n:::\n\n**Artefactos & evidências.** Tabela de exceções com prazos, Relatório de reavaliação, Notificação a owner \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Operação | Calendário (trimestral/semestral), Incidente crítico, Mudança arquitetura | AppSec Engineer + GRC / Compliance | Reavaliação em 5 dias úteis |\n| Validação | Calendário (trimestral/semestral), Incidente crítico, Mudança arquitetura | AppSec Engineer + GRC / Compliance | Reavaliação em 5 dias úteis |\n\n**Ligações úteis.** \n- [Validação Continuada](./addon/validacao-continuada)\n\n---", "title": "US-07 - Ciclo contínuo de revisão e reavaliação de exceções", "traceability": {"line_end": 304, "line_start": 267, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-07-ciclo-continuo-de-revisao-e-reavaliacao-de-excecoes"}, "vector_text": "US-07 - Ciclo contínuo de revisão e reavaliação de exceções\n\n### US-07 - Ciclo contínuo de revisão e reavaliação de exceções\n**Contexto.** Exceções esquecidas tornam-se risco permanente não mitigado. \n\n:::userstory\n**História.** \nComo **AppSec Engineer**, quero **revisar e reavaliar exceções e compensações de forma periódica**, para **garantir que o risco residual continua mitigado e que compensações permanecem eficazes**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** uma exceção ou compensação ativa com prazo de revisão \n **Quando** chega a data de revisão agendada (ou ocorre evento crítico) \n **Então** é reavaliada, revalidada, prorrogada ou encerrada \n\n**Critérios de aceitação (DoD).** \n- [ ] Calendário de revisão definido por criticidade (L3 trimestral, L2 semestral) \n- [ ] Registo de exceção atualizado com nova data de revisão \n- [ ] Reavaliação documentada (mantém-se, prolonga-se, encerra-se) \n- [ ] Owner de Segurança notificado e decisão aprovada \n\n:::\n\n**Artefactos & evidências.** Tabela de exceções com prazos, Relatório de reavaliação, Notificação a owner \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Operação | Calendário (trimestral/semestral), Incidente crítico, Mudança arquitetura | AppSec Engineer + GRC / Compliance | Reavaliação em 5 dias úteis |\n| Validação | Calendário (trimestral/semestral), Incidente crítico, Mudança arquitetura | AppSec Engineer + GRC / Compliance | Reavaliação em 5 dias úteis |\n\n**Ligações úteis.** \n- [Validação Continuada](./addon/validacao-continuada)\n\n---"}
|
|
3691
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-08-repositorio-de-conformidade-por-aplicacao-controlo-sistematico", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-08"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-08-repositorio-de-conformidade-por-aplicacao-controlo-sistematico", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-08 - Repositório de conformidade por aplicação (controlo sistemático)"], "size_estimate": {"approx_tokens": 568, "chars": 2270}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-08 - Repositório de conformidade por aplicação (controlo sistemático)\n**Contexto.** Sem repositório centralizado, estado de segurança fica invisível para auditores e gestão. \n\n:::userstory\n**História.** \nComo **AppSec Engineer + Scrum Master / Team Lead**, quero **manter um repositório estruturado de conformidade para cada aplicação**, para **consolidar estado de todas as práticas SbD-ToE e facilitar auditorias internas e externas**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** uma aplicação classificada como L1, L2 ou L3 \n **Quando** o repositório é criado ou atualizado \n **Então** reflete estado de todos os capítulos (2–13) em checklist estruturado \n\n**Critérios de aceitação (DoD).** \n- [ ] Repositório criado (ficheiro YAML, MD versionado ou dashboard GRC) \n- [ ] Checklist por capítulo (02–13) incluído com estado binário (Sim/Não/Exceção) \n- [ ] Evidência de validação ligada (links a relatórios, testes, scans, auditorias) \n- [ ] Histórico de alterações mantido e auditável \n- [ ] Atualizado por release relevante ou evento crítico \n\n:::\n\n**Artefactos & evidências.** Ficheiro de conformidade (YAML/MD), Links a relatórios de validação, Histórico de versões \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Planeamento | Criação ou atualização do repositório; release relevante ou evento crítico | AppSec Engineer + Scrum Master / Team Lead + GRC / Compliance | Atualização por release ou 5 dias após evento crítico |\n| Execução | Criação ou atualização do repositório; release relevante ou evento crítico | AppSec Engineer + Scrum Master / Team Lead + GRC / Compliance | Atualização por release ou 5 dias após evento crítico |\n| Validação | Criação ou atualização do repositório; release relevante ou evento crítico | AppSec Engineer + Scrum Master / Team Lead + GRC / Compliance | Atualização por release ou 5 dias após evento crítico |\n\n**Ligações úteis.** \n- [Controlo Sistemático das Práticas SbD-ToE](./addon/controlos-praticas-sbd)\n- [Rastreabilidade Organizacional](./addon/rastreabilidade-organizacional)\n\n---", "title": "US-08 - Repositório de conformidade por aplicação (controlo sistemático)", "traceability": {"line_end": 345, "line_start": 305, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-08-repositorio-de-conformidade-por-aplicacao-controlo-sistematico"}, "vector_text": "US-08 - Repositório de conformidade por aplicação (controlo sistemático)\n\n### US-08 - Repositório de conformidade por aplicação (controlo sistemático)\n**Contexto.** Sem repositório centralizado, estado de segurança fica invisível para auditores e gestão. \n\n:::userstory\n**História.** \nComo **AppSec Engineer + Scrum Master / Team Lead**, quero **manter um repositório estruturado de conformidade para cada aplicação**, para **consolidar estado de todas as práticas SbD-ToE e facilitar auditorias internas e externas**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** uma aplicação classificada como L1, L2 ou L3 \n **Quando** o repositório é criado ou atualizado \n **Então** reflete estado de todos os capítulos (2–13) em checklist estruturado \n\n**Critérios de aceitação (DoD).** \n- [ ] Repositório criado (ficheiro YAML, MD versionado ou dashboard GRC) \n- [ ] Checklist por capítulo (02–13) incluído com estado binário (Sim/Não/Exceção) \n- [ ] Evidência de validação ligada (links a relatórios, testes, scans, auditorias) \n- [ ] Histórico de alterações mantido e auditável \n- [ ] Atualizado por release relevante ou evento crítico \n\n:::\n\n**Artefactos & evidências.** Ficheiro de conformidade (YAML/MD), Links a relatórios de validação, Histórico de versões \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Planeamento | Criação ou atualização do repositório; release relevante ou evento crítico | AppSec Engineer + Scrum Master / Team Lead + GRC / Compliance | Atualização por release ou 5 dias após evento crítico |\n| Execução | Criação ou atualização do repositório; release relevante ou evento crítico | AppSec Engineer + Scrum Master / Team Lead + GRC / Compliance | Atualização por release ou 5 dias após evento crítico |\n| Validação | Criação ou atualização do repositório; release relevante ou evento crítico | AppSec Engineer + Scrum Master / Team Lead + GRC / Compliance | Atualização por release ou 5 dias após evento crítico |\n\n**Ligações úteis.** \n- [Controlo Sistemático das Práticas SbD-ToE](./addon/controlos-praticas-sbd)\n- [Rastreabilidade Organizacional](./addon/rastreabilidade-organizacional)\n\n---"}
|
|
3692
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-09-designacao-formal-de-owners-de-seguranca-por-aplicacao", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-09"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-09-designacao-formal-de-owners-de-seguranca-por-aplicacao", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-09 - Designação formal de owners de segurança por aplicação"], "size_estimate": {"approx_tokens": 467, "chars": 1868}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-09 - Designação formal de owners de segurança por aplicação\n**Contexto.** Sem owner claro, responsabilidade dispersa resulta em negligência de exceções e validações. \n\n:::userstory\n**História.** \nComo **Gestão Executiva**, quero **designar formalmente um owner de segurança (Security Champion) por cada aplicação crítica**, para **garantir responsabilização clara, continuidade de decisões de segurança e comunicação de risco**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** uma aplicação classificada como L2 ou L3 \n **Quando** um Security Champion é designado \n **Então** ele é responsável pela submissão de exceções, validações, comunicação de risco e cumprimento de políticas \n\n**Critérios de aceitação (DoD).** \n- [ ] Security Champion designado por escrito (e-mail oficial, documento, HR system) \n- [ ] Responsabilidades documentadas (exceções, validação, comunicação, rastreabilidade) \n- [ ] Formação obrigatória em SbD-ToE completada (Cap. 13 - Formação e Onboarding) \n- [ ] Registo centralizado mantido (Git, Confluence, SharePoint) \n- [ ] Notificação formal ao owner anterior (se houver rotação) \n\n:::\n\n**Artefactos & evidências.** Documento de designação, Comprovativo de formação, Registo centralizado de owners \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Recomendado | Obrigatório | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Planeamento | Aplicação L2/L3; arranque do projeto ou rotação de owner | Gestão Executiva + Security Champion + AppSec Engineer | Designação no arranque do projeto ou mudança de owner |\n\n**Ligações úteis.** \n- [Modelo de Governação](./addon/modelo-governancao)\n- [Formação e Onboarding (Cap. 13)](/sbd-toe/sbd-manual/formacao-onboarding/aplicacao-lifecycle) \n\n---", "title": "US-09 - Designação formal de owners de segurança por aplicação", "traceability": {"line_end": 384, "line_start": 346, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-09-designacao-formal-de-owners-de-seguranca-por-aplicacao"}, "vector_text": "US-09 - Designação formal de owners de segurança por aplicação\n\n### US-09 - Designação formal de owners de segurança por aplicação\n**Contexto.** Sem owner claro, responsabilidade dispersa resulta em negligência de exceções e validações. \n\n:::userstory\n**História.** \nComo **Gestão Executiva**, quero **designar formalmente um owner de segurança (Security Champion) por cada aplicação crítica**, para **garantir responsabilização clara, continuidade de decisões de segurança e comunicação de risco**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** uma aplicação classificada como L2 ou L3 \n **Quando** um Security Champion é designado \n **Então** ele é responsável pela submissão de exceções, validações, comunicação de risco e cumprimento de políticas \n\n**Critérios de aceitação (DoD).** \n- [ ] Security Champion designado por escrito (e-mail oficial, documento, HR system) \n- [ ] Responsabilidades documentadas (exceções, validação, comunicação, rastreabilidade) \n- [ ] Formação obrigatória em SbD-ToE completada (Cap. 13 - Formação e Onboarding) \n- [ ] Registo centralizado mantido (Git, Confluence, SharePoint) \n- [ ] Notificação formal ao owner anterior (se houver rotação) \n\n:::\n\n**Artefactos & evidências.** Documento de designação, Comprovativo de formação, Registo centralizado de owners \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Recomendado | Obrigatório | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Planeamento | Aplicação L2/L3; arranque do projeto ou rotação de owner | Gestão Executiva + Security Champion + AppSec Engineer | Designação no arranque do projeto ou mudança de owner |\n\n**Ligações úteis.** \n- [Modelo de Governação](./addon/modelo-governancao)\n- [Formação e Onboarding (Cap. 13)](/sbd-toe/sbd-manual/formacao-onboarding/aplicacao-lifecycle) \n\n---"}
|
|
3693
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-10-validacao-periodica-de-aplicacoes-ciclo-de-conformidade", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-10"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-10-validacao-periodica-de-aplicacoes-ciclo-de-conformidade", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-10 - Validação periódica de aplicações (ciclo de conformidade)"], "size_estimate": {"approx_tokens": 515, "chars": 2060}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-10 - Validação periódica de aplicações (ciclo de conformidade)\n**Contexto.** Sem validações recorrentes, desvios não são detetados até auditoria ou incidente. \n\n:::userstory\n**História.** \nComo **AppSec Engineer + GRC / Compliance**, quero **executar validações periódicas de conformidade com SbD-ToE em cada aplicação**, para **assegurar que requisitos continuam aplicados e eficazes, detetar desvios cedo, e manter evidência atualizada**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** um calendário de revisões definido por criticidade (L3 trimestral, L2 semestral) \n **Quando** ciclo de revisão chega \n **Então** aplicação é reavaliada, evidência recolhida, e status atualizado no repositório \n\n**Critérios de aceitação (DoD).** \n- [ ] Calendário de revisões definido e comunicado ao Scrum Master / Team Lead \n- [ ] Checklist de validação por capítulo executado \n- [ ] Evidência recolhida (testes, scans, revisões, auditorias externas) \n- [ ] Relatório de conformidade gerado com status claro \n- [ ] Findings e desvios registados em sistema de tracking (Jira, etc.) \n- [ ] Plano de ação criado para não-conformidades críticas \n\n:::\n\n**Artefactos & evidências.** Relatório de validação por ciclo, Checklist preenchido, Plano de ação para findings, Histórico de ciclos \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Anual | Semestral | Trimestral |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Validação | Calendário cíclico, Release relevante, Incidente crítico | AppSec Engineer + GRC / Compliance + Scrum Master / Team Lead | Ciclo completado em 2 semanas desde trigger |\n| Auditoria | Calendário cíclico, Release relevante, Incidente crítico | AppSec Engineer + GRC / Compliance + Scrum Master / Team Lead | Ciclo completado em 2 semanas desde trigger |\n\n**Ligações úteis.** \n- [Validação Continuada](./addon/validacao-continuada)\n- [Controlo Sistemático das Práticas](./addon/controlos-praticas-sbd)\n\n---", "title": "US-10 - Validação periódica de aplicações (ciclo de conformidade)", "traceability": {"line_end": 425, "line_start": 385, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-10-validacao-periodica-de-aplicacoes-ciclo-de-conformidade"}, "vector_text": "US-10 - Validação periódica de aplicações (ciclo de conformidade)\n\n### US-10 - Validação periódica de aplicações (ciclo de conformidade)\n**Contexto.** Sem validações recorrentes, desvios não são detetados até auditoria ou incidente. \n\n:::userstory\n**História.** \nComo **AppSec Engineer + GRC / Compliance**, quero **executar validações periódicas de conformidade com SbD-ToE em cada aplicação**, para **assegurar que requisitos continuam aplicados e eficazes, detetar desvios cedo, e manter evidência atualizada**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** um calendário de revisões definido por criticidade (L3 trimestral, L2 semestral) \n **Quando** ciclo de revisão chega \n **Então** aplicação é reavaliada, evidência recolhida, e status atualizado no repositório \n\n**Critérios de aceitação (DoD).** \n- [ ] Calendário de revisões definido e comunicado ao Scrum Master / Team Lead \n- [ ] Checklist de validação por capítulo executado \n- [ ] Evidência recolhida (testes, scans, revisões, auditorias externas) \n- [ ] Relatório de conformidade gerado com status claro \n- [ ] Findings e desvios registados em sistema de tracking (Jira, etc.) \n- [ ] Plano de ação criado para não-conformidades críticas \n\n:::\n\n**Artefactos & evidências.** Relatório de validação por ciclo, Checklist preenchido, Plano de ação para findings, Histórico de ciclos \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Anual | Semestral | Trimestral |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Validação | Calendário cíclico, Release relevante, Incidente crítico | AppSec Engineer + GRC / Compliance + Scrum Master / Team Lead | Ciclo completado em 2 semanas desde trigger |\n| Auditoria | Calendário cíclico, Release relevante, Incidente crítico | AppSec Engineer + GRC / Compliance + Scrum Master / Team Lead | Ciclo completado em 2 semanas desde trigger |\n\n**Ligações úteis.** \n- [Validação Continuada](./addon/validacao-continuada)\n- [Controlo Sistemático das Práticas](./addon/controlos-praticas-sbd)\n\n---"}
|
|
3694
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-11-consolidacao-de-kpis-de-governacao-e-maturidade", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-11"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-11-consolidacao-de-kpis-de-governacao-e-maturidade", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-11 - Consolidação de KPIs de governação e maturidade"], "size_estimate": {"approx_tokens": 511, "chars": 2043}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-11 - Consolidação de KPIs de governação e maturidade\n**Contexto.** Sem métricas consolidadas, decisão executiva sobre eficácia do SbD-ToE fica sem base empírica. \n\n:::userstory\n**História.** \nComo **CISO + Gestão Executiva**, quero **consolidar e reportar KPIs de governação (exceções, fornecedores auditados, conformidade por capítulo, maturidade)**, para **avaliar objetivamente a maturidade de segurança da organização e tomar decisões estratégicas**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** dados de conformidade e exceções por aplicação \n **Quando** ciclo de reporting chega (trimestral/semestral) \n **Então** KPIs são calculados, visualizados e reportados à direção \n\n**Critérios de aceitação (DoD).** \n- [ ] KPIs definidos (ex: % aplicações com rastreabilidade, % exceções resolvidas, % fornecedores auditados, nível maturidade SAMM/SSDF) \n- [ ] Dashboard configurado com métricas por capítulo e por aplicação \n- [ ] Dados agregados de todos os projetos, equipas e fornecedores \n- [ ] Relatório consolidado entregue à Gestão Executiva, CISO e GRC \n- [ ] Tendências identificadas e recomendações incluídas \n- [ ] Histórico mantido para análise evolutiva \n\n:::\n\n**Artefactos & evidências.** Dashboard de KPIs, Relatório consolidado trimestral/semestral, Histórico de tendências, Análise executiva \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Auditoria | Trimestral (mínimo), Semestral (recomendado) | GRC / Compliance + AppSec Engineer + CISO | Relatório publicado 5 dias após fim do período |\n| Operação | Trimestral (mínimo), Semestral (recomendado) | GRC / Compliance + AppSec Engineer + CISO | Relatório publicado 5 dias após fim do período |\n\n**Ligações úteis.** \n- [Governação e Maturidade](./addon/governancao-maturidade)\n- [Rastreabilidade Organizacional](./addon/rastreabilidade-organizacional)\n\n---", "title": "US-11 - Consolidação de KPIs de governação e maturidade", "traceability": {"line_end": 466, "line_start": 426, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-11-consolidacao-de-kpis-de-governacao-e-maturidade"}, "vector_text": "US-11 - Consolidação de KPIs de governação e maturidade\n\n### US-11 - Consolidação de KPIs de governação e maturidade\n**Contexto.** Sem métricas consolidadas, decisão executiva sobre eficácia do SbD-ToE fica sem base empírica. \n\n:::userstory\n**História.** \nComo **CISO + Gestão Executiva**, quero **consolidar e reportar KPIs de governação (exceções, fornecedores auditados, conformidade por capítulo, maturidade)**, para **avaliar objetivamente a maturidade de segurança da organização e tomar decisões estratégicas**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** dados de conformidade e exceções por aplicação \n **Quando** ciclo de reporting chega (trimestral/semestral) \n **Então** KPIs são calculados, visualizados e reportados à direção \n\n**Critérios de aceitação (DoD).** \n- [ ] KPIs definidos (ex: % aplicações com rastreabilidade, % exceções resolvidas, % fornecedores auditados, nível maturidade SAMM/SSDF) \n- [ ] Dashboard configurado com métricas por capítulo e por aplicação \n- [ ] Dados agregados de todos os projetos, equipas e fornecedores \n- [ ] Relatório consolidado entregue à Gestão Executiva, CISO e GRC \n- [ ] Tendências identificadas e recomendações incluídas \n- [ ] Histórico mantido para análise evolutiva \n\n:::\n\n**Artefactos & evidências.** Dashboard de KPIs, Relatório consolidado trimestral/semestral, Histórico de tendências, Análise executiva \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Auditoria | Trimestral (mínimo), Semestral (recomendado) | GRC / Compliance + AppSec Engineer + CISO | Relatório publicado 5 dias após fim do período |\n| Operação | Trimestral (mínimo), Semestral (recomendado) | GRC / Compliance + AppSec Engineer + CISO | Relatório publicado 5 dias após fim do período |\n\n**Ligações úteis.** \n- [Governação e Maturidade](./addon/governancao-maturidade)\n- [Rastreabilidade Organizacional](./addon/rastreabilidade-organizacional)\n\n---"}
|
|
3695
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-12-formalizacao-de-modelo-de-governacao-por-nivel-de-risco", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-12"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-12-formalizacao-de-modelo-de-governacao-por-nivel-de-risco", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-12 - Formalização de modelo de governação por nível de risco"], "size_estimate": {"approx_tokens": 634, "chars": 2534}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-12 - Formalização de modelo de governação por nível de risco\n**Contexto.** Sem modelo formal documentado, decisões de segurança ficam dispersas entre AppSec, Gestão e Jurídico. A falta de critérios explícitos para aprovação por nível resulta em inconsistência, risco não rastreável, e desconfiança dos stakeholders.\n\n:::userstory\n**História.** \nComo **CISO + AppSec Engineer**, quero **formalizar e documentar o modelo de governação com níveis de alçada explícitos, papéis e responsabilidades claras**, para **garantir que decisões de segurança são tomadas com autoridade apropriada, consistência, e rastreabilidade completa**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** que a organização adota SbD-ToE \n **Quando** um novo modelo de governação é definido ou revisado \n **Então** ele é documentado com alçadas por L1–L3, aprovado por direção, e comunicado a todos os stakeholders \n\n**Critérios de aceitação (DoD).** \n- [ ] Documento formal de \"Política de Governação de Segurança SbD-ToE\" aprovado por direção \n- [ ] Níveis de alçada definidos explicitamente: L1 (Gestor Aplicação), L2 (AppSec + Gestor), L3 (CISO + AppSec + Direção) \n- [ ] Papéis e responsabilidades mapeados por função (Dev, AppSec, Gestão, Jurídico, GRC, CISO) \n- [ ] Template de registo de decisão criado (Jira / SharePoint / Git) com campos obrigatórios \n- [ ] Fluxo de escalação documentado com SLAs por nível \n- [ ] Formação executada para todos os approvers (Cap. 13 - Trilho Formação Governação) \n- [ ] Comunicação oficial publicada em canais corporativos \n\n:::\n\n**Artefactos & evidências.** Documento de Política, Template de Decisão, Repositório de decisões registadas, Comprovativo de formação dos approvers, Email de comunicação \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Planeamento | Arranque SbD-ToE, revisão anual, mudança organizacional | CISO + AppSec Engineer + GRC / Compliance (Jurídico) | Publicação em 2 semanas |\n| Execução | Arranque SbD-ToE, revisão anual, mudança organizacional | CISO + AppSec Engineer + GRC / Compliance (Jurídico) | Publicação em 2 semanas |\n\n**Ligações úteis.** \n- [Modelo de Governação](./addon/modelo-governancao)\n- [Exemplos de Decisão](./addon/exemplos-aplicacao-governanca)\n- [Formação de Governação (Cap. 13)](/sbd-toe/sbd-manual/formacao-onboarding/aplicacao-lifecycle) \n\n---", "title": "US-12 - Formalização de modelo de governação por nível de risco", "traceability": {"line_end": 509, "line_start": 467, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-12-formalizacao-de-modelo-de-governacao-por-nivel-de-risco"}, "vector_text": "US-12 - Formalização de modelo de governação por nível de risco\n\n### US-12 - Formalização de modelo de governação por nível de risco\n**Contexto.** Sem modelo formal documentado, decisões de segurança ficam dispersas entre AppSec, Gestão e Jurídico. A falta de critérios explícitos para aprovação por nível resulta em inconsistência, risco não rastreável, e desconfiança dos stakeholders.\n\n:::userstory\n**História.** \nComo **CISO + AppSec Engineer**, quero **formalizar e documentar o modelo de governação com níveis de alçada explícitos, papéis e responsabilidades claras**, para **garantir que decisões de segurança são tomadas com autoridade apropriada, consistência, e rastreabilidade completa**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** que a organização adota SbD-ToE \n **Quando** um novo modelo de governação é definido ou revisado \n **Então** ele é documentado com alçadas por L1–L3, aprovado por direção, e comunicado a todos os stakeholders \n\n**Critérios de aceitação (DoD).** \n- [ ] Documento formal de \"Política de Governação de Segurança SbD-ToE\" aprovado por direção \n- [ ] Níveis de alçada definidos explicitamente: L1 (Gestor Aplicação), L2 (AppSec + Gestor), L3 (CISO + AppSec + Direção) \n- [ ] Papéis e responsabilidades mapeados por função (Dev, AppSec, Gestão, Jurídico, GRC, CISO) \n- [ ] Template de registo de decisão criado (Jira / SharePoint / Git) com campos obrigatórios \n- [ ] Fluxo de escalação documentado com SLAs por nível \n- [ ] Formação executada para todos os approvers (Cap. 13 - Trilho Formação Governação) \n- [ ] Comunicação oficial publicada em canais corporativos \n\n:::\n\n**Artefactos & evidências.** Documento de Política, Template de Decisão, Repositório de decisões registadas, Comprovativo de formação dos approvers, Email de comunicação \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Planeamento | Arranque SbD-ToE, revisão anual, mudança organizacional | CISO + AppSec Engineer + GRC / Compliance (Jurídico) | Publicação em 2 semanas |\n| Execução | Arranque SbD-ToE, revisão anual, mudança organizacional | CISO + AppSec Engineer + GRC / Compliance (Jurídico) | Publicação em 2 semanas |\n\n**Ligações úteis.** \n- [Modelo de Governação](./addon/modelo-governancao)\n- [Exemplos de Decisão](./addon/exemplos-aplicacao-governanca)\n- [Formação de Governação (Cap. 13)](/sbd-toe/sbd-manual/formacao-onboarding/aplicacao-lifecycle) \n\n---"}
|
|
3696
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-13-controlo-sistematico-e-periodico-por-capitulo-sbd-toe", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-13"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-13-controlo-sistematico-e-periodico-por-capitulo-sbd-toe", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-13 - Controlo sistemático e periódico por capítulo SbD-ToE"], "size_estimate": {"approx_tokens": 900, "chars": 3597}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-13 - Controlo sistemático e periódico por capítulo SbD-ToE\n**Contexto.** Sem checklist centralizado de conformidade, o estado de conformidade de uma aplicação com Cap. 2–13 fica invisível. Desvios não são detetados até auditoria ou incidente crítico. Gestão não tem visibilidade do progresso.\n\n:::userstory\n**História.** \nComo **AppSec Engineer + Scrum Master / Team Lead**, quero **manter um checklist centralizado, versionado e auditável de conformidade com todos os capítulos SbD-ToE (2–13), com verificação periódica por release ou evento crítico**, para **consolidar estado real de todas as práticas e facilitar auditorias, decisão de risco, e demonstração de conformidade normativa**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** uma aplicação classificada como L1, L2 ou L3 \n **Quando** um ciclo de validação é acionado (por release, trimestral L3, semestral L2, ou evento crítico) \n **Então** checklist é preenchido com estado, evidência é ligada, e relatório é gerado \n\n**Critérios de aceitação (DoD).** \n- [ ] Ficheiro de checklist versionado criado em repositório (YAML, MD ou dashboard GRC) com estrutura: Capítulo | Prática | Status (Sim/Não/Exceção/N/A) | Evidência (link/referência) | Owner | Data de validação \n- [ ] Integração com sistema de controlo de versões (Git) ou GRC com histórico auditável \n- [ ] Triggers definidos e automatizados: release relevante, evento crítico (incidente, CVE), ciclo programado (L3 trimestral, L2 semestral, L1 anual) \n- [ ] Histórico mantido com alterações datadas e responsáveis (trilha de auditoria) \n- [ ] Relatório consolidado gerado por ciclo com % conformidade, achados críticos, e plano de acção \n- [ ] Artefactos de evidência ligados ou referenciados no checklist (links a testes, scans, relatórios, auditorias) \n- [ ] Notificação automática enviada a Scrum Master / Team Lead e AppSec Engineer quando ciclo é acionado \n\n:::\n\n**Artefactos & evidências.** Ficheiro de checklist versionado (YAML/MD), Git history ou dashboard GRC, Relatórios por ciclo, Links a artefactos de validação, Plano de acção para não-conformidades, Histórico de versões \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Planeamento | Release relevante, evento crítico, ciclo programado (trimestral/semestral/anual) | AppSec Engineer (validação) + Scrum Master / Team Lead (preenchimento) + GRC / Compliance (consolidação) | Atualização em 5 dias úteis após trigger |\n| Execução | Release relevante, evento crítico, ciclo programado (trimestral/semestral/anual) | AppSec Engineer (validação) + Scrum Master / Team Lead (preenchimento) + GRC / Compliance (consolidação) | Atualização em 5 dias úteis após trigger |\n| Validação | Release relevante, evento crítico, ciclo programado (trimestral/semestral/anual) | AppSec Engineer (validação) + Scrum Master / Team Lead (preenchimento) + GRC / Compliance (consolidação) | Atualização em 5 dias úteis após trigger |\n| Auditoria | Release relevante, evento crítico, ciclo programado (trimestral/semestral/anual) | AppSec Engineer (validação) + Scrum Master / Team Lead (preenchimento) + GRC / Compliance (consolidação) | Atualização em 5 dias úteis após trigger |\n\n**Ligações úteis.** \n- [Controlo Sistemático das Práticas SbD-ToE](./addon/controlos-praticas-sbd)\n- [Rastreabilidade Organizacional](./addon/rastreabilidade-organizacional)\n- [Validação Periódica](./addon/validacao-continuada)\n\n---", "title": "US-13 - Controlo sistemático e periódico por capítulo SbD-ToE", "traceability": {"line_end": 554, "line_start": 510, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-13-controlo-sistematico-e-periodico-por-capitulo-sbd-toe"}, "vector_text": "US-13 - Controlo sistemático e periódico por capítulo SbD-ToE\n\n### US-13 - Controlo sistemático e periódico por capítulo SbD-ToE\n**Contexto.** Sem checklist centralizado de conformidade, o estado de conformidade de uma aplicação com Cap. 2–13 fica invisível. Desvios não são detetados até auditoria ou incidente crítico. Gestão não tem visibilidade do progresso.\n\n:::userstory\n**História.** \nComo **AppSec Engineer + Scrum Master / Team Lead**, quero **manter um checklist centralizado, versionado e auditável de conformidade com todos os capítulos SbD-ToE (2–13), com verificação periódica por release ou evento crítico**, para **consolidar estado real de todas as práticas e facilitar auditorias, decisão de risco, e demonstração de conformidade normativa**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** uma aplicação classificada como L1, L2 ou L3 \n **Quando** um ciclo de validação é acionado (por release, trimestral L3, semestral L2, ou evento crítico) \n **Então** checklist é preenchido com estado, evidência é ligada, e relatório é gerado \n\n**Critérios de aceitação (DoD).** \n- [ ] Ficheiro de checklist versionado criado em repositório (YAML, MD ou dashboard GRC) com estrutura: Capítulo | Prática | Status (Sim/Não/Exceção/N/A) | Evidência (link/referência) | Owner | Data de validação \n- [ ] Integração com sistema de controlo de versões (Git) ou GRC com histórico auditável \n- [ ] Triggers definidos e automatizados: release relevante, evento crítico (incidente, CVE), ciclo programado (L3 trimestral, L2 semestral, L1 anual) \n- [ ] Histórico mantido com alterações datadas e responsáveis (trilha de auditoria) \n- [ ] Relatório consolidado gerado por ciclo com % conformidade, achados críticos, e plano de acção \n- [ ] Artefactos de evidência ligados ou referenciados no checklist (links a testes, scans, relatórios, auditorias) \n- [ ] Notificação automática enviada a Scrum Master / Team Lead e AppSec Engineer quando ciclo é acionado \n\n:::\n\n**Artefactos & evidências.** Ficheiro de checklist versionado (YAML/MD), Git history ou dashboard GRC, Relatórios por ciclo, Links a artefactos de validação, Plano de acção para não-conformidades, Histórico de versões \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Planeamento | Release relevante, evento crítico, ciclo programado (trimestral/semestral/anual) | AppSec Engineer (validação) + Scrum Master / Team Lead (preenchimento) + GRC / Compliance (consolidação) | Atualização em 5 dias úteis após trigger |\n| Execução | Release relevante, evento crítico, ciclo programado (trimestral/semestral/anual) | AppSec Engineer (validação) + Scrum Master / Team Lead (preenchimento) + GRC / Compliance (consolidação) | Atualização em 5 dias úteis após trigger |\n| Validação | Release relevante, evento crítico, ciclo programado (trimestral/semestral/anual) | AppSec Engineer (validação) + Scrum Master / Team Lead (preenchimento) + GRC / Compliance (consolidação) | Atualização em 5 dias úteis após trigger |\n| Auditoria | Release relevante, evento crítico, ciclo programado (trimestral/semestral/anual) | AppSec Engineer (validação) + Scrum Master / Team Lead (preenchimento) + GRC / Compliance (consolidação) | Atualização em 5 dias úteis após trigger |\n\n**Ligações úteis.** \n- [Controlo Sistemático das Práticas SbD-ToE](./addon/controlos-praticas-sbd)\n- [Rastreabilidade Organizacional](./addon/rastreabilidade-organizacional)\n- [Validação Periódica](./addon/validacao-continuada)\n\n---"}
|
|
3697
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-14-reavaliacao-continua-e-rotacao-de-fornecedores-pos-onboarding", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-14"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-14-reavaliacao-continua-e-rotacao-de-fornecedores-pos-onboarding", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-14 - Reavaliação contínua e rotação de fornecedores pós-onboarding"], "size_estimate": {"approx_tokens": 841, "chars": 3363}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-14 - Reavaliação contínua e rotação de fornecedores pós-onboarding\n**Contexto.** Fornecedores são validados no onboarding, mas sem revisão periódica, desvios surgem ao longo do tempo (novos CVEs não mitigados, SLA não cumprido, mudanças de propriedade, evolução do risco). Risco residual acumula invisível. Contratos expiram sem renovação de validação.\n\n:::userstory\n**História.** \nComo **AppSec Engineer + GRC / Compliance (Procurement Officer)**, quero **reavalia e reaprovar fornecedores periodicamente (anual por defaut, semestral para L2, trimestral para L3), com validação técnica atualizada, análise de compliance SLA, e escalonamento para decisão de penalização ou substituição se necessário**, para **assegurar que continuam a cumprir requisitos e SLA, que risco é mitigado, e que decisões de continuidade são baseadas em evidência**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um fornecedor ativo com contrato vigente \n **Quando** chega data de revisão agendada (calendário) ou evento crítico ocorre (incidente, CVE crítico, mudança SLA) \n **Então** fornecedor é reavaliado com questionário atualizado, evidência técnica validada (SBOM, SLA compliance, mudanças) e decisão é formalizada \n\n**Critérios de aceitação (DoD).** \n- [ ] Calendário de revisão de fornecedores definido e comunicado (anual mínimo, 6 meses para L2, trimestral para L3, ou por evento crítico) \n- [ ] Questionário atualizado com perguntas de segurança e SLA enviado ao fornecedor \n- [ ] Análise técnica documentada (AppSec): SBOM validado, CVEs analisados, SLA compliance verificado, mudanças organizacionais/técnicas identificadas \n- [ ] Decisão formalizada e registada em GRC: Aprovado / Exceção criada / Penalização proposta / Rescisão iniciada \n- [ ] Owner notificado formalmente por email com decisão e próxima data de revisão \n- [ ] Plano de mitigação criado se gaps identificados (prazo, responsável AppSec, validação esperada) \n- [ ] Registo atualizado no repositório de fornecedores com data, decisor, e histórico \n\n:::\n\n**Artefactos & evidências.** Calendário de revisão, Questionário atualizado + respostas, Análise técnica documentada, Decisão registada em GRC, Comunicação formal ao fornecedor, Plano de mitigação se aplicável, Histórico de decisões \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Anual | Semestral | Trimestral / evento crítico |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Validação | Calendário programado (anual/semestral), Incidente crítico, CVE crítico não mitigado, Mudança de contrato/propriedade/SLA | AppSec Engineer (análise técnica) + GRC / Compliance (Procurement Officer — coordenação; decisão e registo) | Reavaliação completada em 2 semanas desde trigger |\n| Operação | Calendário programado (anual/semestral), Incidente crítico, CVE crítico não mitigado, Mudança de contrato/propriedade/SLA | AppSec Engineer (análise técnica) + GRC / Compliance (Procurement Officer — coordenação; decisão e registo) | Reavaliação completada em 2 semanas desde trigger |\n\n**Ligações úteis.** \n- [Modelo de Validação de Fornecedores](./addon/modelo-validacao-fornecedores)\n- [Validação Continuada](./addon/validacao-continuada)\n- [Exemplos de Aplicação](./addon/exemplos-aplicacao-governanca)\n\n---", "title": "US-14 - Reavaliação contínua e rotação de fornecedores pós-onboarding", "traceability": {"line_end": 597, "line_start": 555, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-14-reavaliacao-continua-e-rotacao-de-fornecedores-pos-onboarding"}, "vector_text": "US-14 - Reavaliação contínua e rotação de fornecedores pós-onboarding\n\n### US-14 - Reavaliação contínua e rotação de fornecedores pós-onboarding\n**Contexto.** Fornecedores são validados no onboarding, mas sem revisão periódica, desvios surgem ao longo do tempo (novos CVEs não mitigados, SLA não cumprido, mudanças de propriedade, evolução do risco). Risco residual acumula invisível. Contratos expiram sem renovação de validação.\n\n:::userstory\n**História.** \nComo **AppSec Engineer + GRC / Compliance (Procurement Officer)**, quero **reavalia e reaprovar fornecedores periodicamente (anual por defaut, semestral para L2, trimestral para L3), com validação técnica atualizada, análise de compliance SLA, e escalonamento para decisão de penalização ou substituição se necessário**, para **assegurar que continuam a cumprir requisitos e SLA, que risco é mitigado, e que decisões de continuidade são baseadas em evidência**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um fornecedor ativo com contrato vigente \n **Quando** chega data de revisão agendada (calendário) ou evento crítico ocorre (incidente, CVE crítico, mudança SLA) \n **Então** fornecedor é reavaliado com questionário atualizado, evidência técnica validada (SBOM, SLA compliance, mudanças) e decisão é formalizada \n\n**Critérios de aceitação (DoD).** \n- [ ] Calendário de revisão de fornecedores definido e comunicado (anual mínimo, 6 meses para L2, trimestral para L3, ou por evento crítico) \n- [ ] Questionário atualizado com perguntas de segurança e SLA enviado ao fornecedor \n- [ ] Análise técnica documentada (AppSec): SBOM validado, CVEs analisados, SLA compliance verificado, mudanças organizacionais/técnicas identificadas \n- [ ] Decisão formalizada e registada em GRC: Aprovado / Exceção criada / Penalização proposta / Rescisão iniciada \n- [ ] Owner notificado formalmente por email com decisão e próxima data de revisão \n- [ ] Plano de mitigação criado se gaps identificados (prazo, responsável AppSec, validação esperada) \n- [ ] Registo atualizado no repositório de fornecedores com data, decisor, e histórico \n\n:::\n\n**Artefactos & evidências.** Calendário de revisão, Questionário atualizado + respostas, Análise técnica documentada, Decisão registada em GRC, Comunicação formal ao fornecedor, Plano de mitigação se aplicável, Histórico de decisões \n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Anual | Semestral | Trimestral / evento crítico |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Validação | Calendário programado (anual/semestral), Incidente crítico, CVE crítico não mitigado, Mudança de contrato/propriedade/SLA | AppSec Engineer (análise técnica) + GRC / Compliance (Procurement Officer — coordenação; decisão e registo) | Reavaliação completada em 2 semanas desde trigger |\n| Operação | Calendário programado (anual/semestral), Incidente crítico, CVE crítico não mitigado, Mudança de contrato/propriedade/SLA | AppSec Engineer (análise técnica) + GRC / Compliance (Procurement Officer — coordenação; decisão e registo) | Reavaliação completada em 2 semanas desde trigger |\n\n**Ligações úteis.** \n- [Modelo de Validação de Fornecedores](./addon/modelo-validacao-fornecedores)\n- [Validação Continuada](./addon/validacao-continuada)\n- [Exemplos de Aplicação](./addon/exemplos-aplicacao-governanca)\n\n---"}
|
|
3698
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-15-preparacao-tecnica-e-validacao-de-contractors-pre-acesso", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": ["governance-and-procurement"], "phase": ["govern"], "risk_level": ["L2", "L3"]}, "mentioned_entities": {"Requirement": ["GOV-013"], "UserStory": ["US-06", "US-15"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-15-preparacao-tecnica-e-validacao-de-contractors-pre-acesso", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-15 - Preparação Técnica e Validação de Contractors pré-Acesso"], "size_estimate": {"approx_tokens": 784, "chars": 3133}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-15 - Preparação Técnica e Validação de Contractors pré-Acesso\n**Contexto.** Contractors ganham acesso sem compreender políticas de segurança, ferramentas obrigatórias, ou procedimentos. Risco de erro involuntário (credenciais expostas, acesso a dados não autorizados, práticas inseguras).\n\n:::userstory\n**História.** \nComo **Security Champion (HR/Recruiter)**, quero **executar processo estruturado de preparação técnica de contractors (triagem, formação obrigatória, teste de compreensão, ambiente sandbox) antes de ganhem acesso a sistemas**, para **garantir que estão preparados, compreenderam políticas fundamentais, e podem trabalhar seguramente**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um novo contractor aprovado por Procurement (US-06) e contrato assinado \n **Quando** chega data de início do projeto \n **Então** trilho de preparação é acionado: formação obrigatória, quiz, sandbox setup, confirmação de NDA \n\n**Critérios de aceitação (DoD).** \n- [ ] Checklist de preparação preenchido (triagem de skills, nível de segurança esperado, formação requerida definida) \n- [ ] Trilho de formação baseado em perfil (Dev, DevOps, QA, etc.) iniciado em LMS ou plataforma de treino \n- [ ] Quiz de compreensão de políticas de segurança completado (score mínimo 80%) \n- [ ] Acesso a ambiente sandbox fornecido para prática (ex.: repositório Git privado, aplicação demo, ferramentas de segurança) \n- [ ] NDA e confidentiality agreement assinados digitalmente com timestamp \n- [ ] Checklist de onboarding técnico preenchido e validado pela equipa (Security Champion + Scrum Master / Team Lead) \n- [ ] Acesso real a sistemas concedido apenas após todos os passos de aprovação \n- [ ] Registo de \"ready for access\" documentado em GRC com data, validador, e referência a todas as validações \n\n:::\n\n**Artefactos & evidências.** Checklist de preparação preenchido, LMS enrollment confirmado, Quiz score validado, Sandbox access credentials, Acordos assinados digitalmente, Checklist de onboarding, Registo GRC de \"ready for access\"\n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Recomendado | Obrigatório + quiz validado |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Planeamento | Contrato assinado, data de início do projeto | Security Champion (coordenação HR) + AppSec Engineer (validação) + Scrum Master / Team Lead (sandbox setup) | Conclusão em 2–3 dias úteis antes de data de início; Notificação: Contractor informado via email sobre trilho |\n\n**Ligações úteis.** \n- [Cap. 13 - Formação e Onboarding](/sbd-toe/sbd-manual/formacao-onboarding/aplicacao-lifecycle) \n- [Validação de Fornecedores - US-06](#us-06---execução-de-fluxo-formal-de-validação-de-fornecedores) \n- [Template de Validação de Contractors](/sbd-toe/sbd-manual/governanca-contratacao/addon/template-validacao-contractors)\n- [Guia de Preparação Sandbox](/sbd-toe/sbd-manual/formacao-onboarding/addon/guia-preparacao-sandbox) \n- Grounding canónico: [`GOV-013`](./addon/catalogo-requisitos-governanca) \n\n---", "title": "US-15 - Preparação Técnica e Validação de Contractors pré-Acesso", "traceability": {"line_end": 642, "line_start": 598, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-15-preparacao-tecnica-e-validacao-de-contractors-pre-acesso"}, "vector_text": "US-15 - Preparação Técnica e Validação de Contractors pré-Acesso\n\n### US-15 - Preparação Técnica e Validação de Contractors pré-Acesso\n**Contexto.** Contractors ganham acesso sem compreender políticas de segurança, ferramentas obrigatórias, ou procedimentos. Risco de erro involuntário (credenciais expostas, acesso a dados não autorizados, práticas inseguras).\n\n:::userstory\n**História.** \nComo **Security Champion (HR/Recruiter)**, quero **executar processo estruturado de preparação técnica de contractors (triagem, formação obrigatória, teste de compreensão, ambiente sandbox) antes de ganhem acesso a sistemas**, para **garantir que estão preparados, compreenderam políticas fundamentais, e podem trabalhar seguramente**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um novo contractor aprovado por Procurement (US-06) e contrato assinado \n **Quando** chega data de início do projeto \n **Então** trilho de preparação é acionado: formação obrigatória, quiz, sandbox setup, confirmação de NDA \n\n**Critérios de aceitação (DoD).** \n- [ ] Checklist de preparação preenchido (triagem de skills, nível de segurança esperado, formação requerida definida) \n- [ ] Trilho de formação baseado em perfil (Dev, DevOps, QA, etc.) iniciado em LMS ou plataforma de treino \n- [ ] Quiz de compreensão de políticas de segurança completado (score mínimo 80%) \n- [ ] Acesso a ambiente sandbox fornecido para prática (ex.: repositório Git privado, aplicação demo, ferramentas de segurança) \n- [ ] NDA e confidentiality agreement assinados digitalmente com timestamp \n- [ ] Checklist de onboarding técnico preenchido e validado pela equipa (Security Champion + Scrum Master / Team Lead) \n- [ ] Acesso real a sistemas concedido apenas após todos os passos de aprovação \n- [ ] Registo de \"ready for access\" documentado em GRC com data, validador, e referência a todas as validações \n\n:::\n\n**Artefactos & evidências.** Checklist de preparação preenchido, LMS enrollment confirmado, Quiz score validado, Sandbox access credentials, Acordos assinados digitalmente, Checklist de onboarding, Registo GRC de \"ready for access\"\n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Recomendado | Obrigatório + quiz validado |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Planeamento | Contrato assinado, data de início do projeto | Security Champion (coordenação HR) + AppSec Engineer (validação) + Scrum Master / Team Lead (sandbox setup) | Conclusão em 2–3 dias úteis antes de data de início; Notificação: Contractor informado via email sobre trilho |\n\n**Ligações úteis.** \n- [Cap. 13 - Formação e Onboarding](/sbd-toe/sbd-manual/formacao-onboarding/aplicacao-lifecycle) \n- [Validação de Fornecedores - US-06](#us-06---execução-de-fluxo-formal-de-validação-de-fornecedores) \n- [Template de Validação de Contractors](/sbd-toe/sbd-manual/governanca-contratacao/addon/template-validacao-contractors)\n- [Guia de Preparação Sandbox](/sbd-toe/sbd-manual/formacao-onboarding/addon/guia-preparacao-sandbox) \n- Grounding canónico: [`GOV-013`](./addon/catalogo-requisitos-governanca) \n\n---"}
|
|
3699
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-16-trilho-de-formacao-obrigatoria-pre-acesso-contractors", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": ["governance-and-procurement"], "phase": ["govern"], "risk_level": ["L2", "L3"]}, "mentioned_entities": {"Requirement": ["GOV-013"], "UserStory": ["US-06", "US-09", "US-15", "US-16"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-16-trilho-de-formacao-obrigatoria-pre-acesso-contractors", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-16 - Trilho de Formação Obrigatória pré-Acesso (Contractors)"], "size_estimate": {"approx_tokens": 858, "chars": 3430}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-16 - Trilho de Formação Obrigatória pré-Acesso (Contractors)\n**Contexto.** Contractors iniciados sem completar formação de segurança obrigatória. Falta de integração clara entre Cap. 13 (Formação) e Cap. 14 (Governação): quem aprova, qual o SLA, como é tracked.\n\n:::userstory\n**História.** \nComo **CISO + Security Champion (Training Manager)**, quero **definir e executar trilho de formação obrigatória por perfil de contractor, com SLA explícito de conclusão antes de acesso técnico**, para **garantir consciência de segurança mínima, conformidade regulatória (DORA, NIS2), e rastreabilidade de preparação**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um contractor novo contratado \n **Quando** trilho de formação é atribuído em LMS \n **Então** deve completar cursos obrigatórios, passar quiz, e ter registo consolidado antes de acesso real \n\n**Critérios de aceitação (DoD).** \n- [ ] Trilho de formação definido por perfil (Developer, DevOps, QA, Arquitetura, etc.) com duração estimada \n- [ ] Cursos obrigatórios listados e mapeados a capítulos SbD-ToE: \n - **[O1] Security Awareness Geral** (2h) → Cap. 00 + 02 + 14 \n - **[O2] SbD-ToE Overview** (1h) → Cap. 01–03 (risco, requisitos, threat modeling) \n - **[O3] Secure Coding & SAST** (2h) → Cap. 06 (se developer) \n - **[O4] CI/CD Security & Artefacts** (1h) → Cap. 07 (se DevOps) \n - **[O5] Incident Response Basics** (1h) → Cap. 12 \n - **[O6] Supply Chain & Dependências** (1h) → Cap. 05 (se envolvido com builds) \n- [ ] Quiz de avaliação por curso (score mínimo 80%) completado \n- [ ] Registo centralizado atualizado (LMS ou Confluence) com datas, scores, validador \n- [ ] SLA de conclusão comunicado ao contractor: Máximo **5 dias úteis antes de data de início** \n- [ ] Notificação automática enviada se SLA em risco (ex.: 2 dias antes da deadline) \n- [ ] Sign-off de \"formação completa\" fornecido ao AppSec Engineer (libera acesso técnico) \n- [ ] Histórico mantido por 3 anos (DORA, NIS2 requirement) \n\n:::\n\n**Artefactos & evidências.** Trilho de formação definido por perfil, LMS enrollment, Quiz completion records, Sign-off de conclusão, SLA compliance checklist, Notificações enviadas\n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Obrigatório | Obrigatório + 80% score requerido |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Planeamento | Contractor aprovado (fim US-06/US-15) | AppSec Engineer (validação de conclusão) + Security Champion (Training Manager — coordenação trilho; rastreabilidade HR) | Formação completa antes de acesso real; Notificação: Semanais se em risco, daily se `<`3 dias |\n| Execução | Contractor aprovado (fim US-06/US-15) | AppSec Engineer (validação de conclusão) + Security Champion (Training Manager — coordenação trilho; rastreabilidade HR) | Formação completa antes de acesso real; Notificação: Semanais se em risco, daily se `<`3 dias |\n\n**Ligações úteis.** \n- [Cap. 13 - Formação e Onboarding](/sbd-toe/sbd-manual/formacao-onboarding/aplicacao-lifecycle) \n- [Designação de Owners de Segurança - US-09](#us-09---designação-formal-de-owners-de-segurança-por-aplicação) \n- [Preparação Técnica - US-15](#us-15---preparação-técnica-e-validação-de-contractors-pré-acesso) \n- Grounding canónico: [`GOV-013`](./addon/catalogo-requisitos-governanca) \n\n---", "title": "US-16 - Trilho de Formação Obrigatória pré-Acesso (Contractors)", "traceability": {"line_end": 693, "line_start": 643, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-16-trilho-de-formacao-obrigatoria-pre-acesso-contractors"}, "vector_text": "US-16 - Trilho de Formação Obrigatória pré-Acesso (Contractors)\n\n### US-16 - Trilho de Formação Obrigatória pré-Acesso (Contractors)\n**Contexto.** Contractors iniciados sem completar formação de segurança obrigatória. Falta de integração clara entre Cap. 13 (Formação) e Cap. 14 (Governação): quem aprova, qual o SLA, como é tracked.\n\n:::userstory\n**História.** \nComo **CISO + Security Champion (Training Manager)**, quero **definir e executar trilho de formação obrigatória por perfil de contractor, com SLA explícito de conclusão antes de acesso técnico**, para **garantir consciência de segurança mínima, conformidade regulatória (DORA, NIS2), e rastreabilidade de preparação**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um contractor novo contratado \n **Quando** trilho de formação é atribuído em LMS \n **Então** deve completar cursos obrigatórios, passar quiz, e ter registo consolidado antes de acesso real \n\n**Critérios de aceitação (DoD).** \n- [ ] Trilho de formação definido por perfil (Developer, DevOps, QA, Arquitetura, etc.) com duração estimada \n- [ ] Cursos obrigatórios listados e mapeados a capítulos SbD-ToE: \n - **[O1] Security Awareness Geral** (2h) → Cap. 00 + 02 + 14 \n - **[O2] SbD-ToE Overview** (1h) → Cap. 01–03 (risco, requisitos, threat modeling) \n - **[O3] Secure Coding & SAST** (2h) → Cap. 06 (se developer) \n - **[O4] CI/CD Security & Artefacts** (1h) → Cap. 07 (se DevOps) \n - **[O5] Incident Response Basics** (1h) → Cap. 12 \n - **[O6] Supply Chain & Dependências** (1h) → Cap. 05 (se envolvido com builds) \n- [ ] Quiz de avaliação por curso (score mínimo 80%) completado \n- [ ] Registo centralizado atualizado (LMS ou Confluence) com datas, scores, validador \n- [ ] SLA de conclusão comunicado ao contractor: Máximo **5 dias úteis antes de data de início** \n- [ ] Notificação automática enviada se SLA em risco (ex.: 2 dias antes da deadline) \n- [ ] Sign-off de \"formação completa\" fornecido ao AppSec Engineer (libera acesso técnico) \n- [ ] Histórico mantido por 3 anos (DORA, NIS2 requirement) \n\n:::\n\n**Artefactos & evidências.** Trilho de formação definido por perfil, LMS enrollment, Quiz completion records, Sign-off de conclusão, SLA compliance checklist, Notificações enviadas\n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Obrigatório | Obrigatório + 80% score requerido |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Planeamento | Contractor aprovado (fim US-06/US-15) | AppSec Engineer (validação de conclusão) + Security Champion (Training Manager — coordenação trilho; rastreabilidade HR) | Formação completa antes de acesso real; Notificação: Semanais se em risco, daily se `<`3 dias |\n| Execução | Contractor aprovado (fim US-06/US-15) | AppSec Engineer (validação de conclusão) + Security Champion (Training Manager — coordenação trilho; rastreabilidade HR) | Formação completa antes de acesso real; Notificação: Semanais se em risco, daily se `<`3 dias |\n\n**Ligações úteis.** \n- [Cap. 13 - Formação e Onboarding](/sbd-toe/sbd-manual/formacao-onboarding/aplicacao-lifecycle) \n- [Designação de Owners de Segurança - US-09](#us-09---designação-formal-de-owners-de-segurança-por-aplicação) \n- [Preparação Técnica - US-15](#us-15---preparação-técnica-e-validação-de-contractors-pré-acesso) \n- Grounding canónico: [`GOV-013`](./addon/catalogo-requisitos-governanca) \n\n---"}
|
|
3700
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-17-offboarding-seguro-de-contractors-e-rescisao-de-fornecedores", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-14", "US-15", "US-17"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-17-offboarding-seguro-de-contractors-e-rescisao-de-fornecedores", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-17 - Offboarding Seguro de Contractors e Rescisão de Fornecedores"], "size_estimate": {"approx_tokens": 881, "chars": 3521}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-17 - Offboarding Seguro de Contractors e Rescisão de Fornecedores\n**Contexto.** Contractors terminam projeto ou contrato sem processo formal: acesso mantém-se ativo, ativos (código, credenciais, documentos) não são recuperados. Risco de vazamento pós-rescisão, acesso residual, violação de confidencialidade.\n\n:::userstory\n**História.** \nComo **Security Champion (HR) + DevOps / SRE**, quero **executar processo formal e automático de offboarding seguro quando contractor termina ou fornecedor é rescindido**, para **garantir que acesso é revogado completamente, ativos recuperados, confidencialidade mantida, e conformidade legal assegurada**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um contractor cuja data de termo é conhecida (ou fornecedor rescindido com aviso) \n **Quando** data de offboarding chega \n **Então** acesso é revogado, ativos recuperados, e conclusão documentada \n\n**Critérios de aceitação (DoD).** \n- [ ] Checklist de offboarding preparado 2 semanas antes (DevOps / SRE, Security Champion, AppSec Engineer, Scrum Master / Team Lead) \n- [ ] Notificação formal enviada ao contractor/fornecedor com data exata de desativação \n- [ ] Acesso a sistemas revogado (no máximo 24h após data de termo): \n - Contas de utilizador desativadas em Git, Jira, CI/CD \n - SSH keys e API tokens removidos \n - VPN, cloud IAM access revogado \n - MFA removido \n - Emails corporativos desativados (se aplicável) \n- [ ] Ativos recuperados: \n - Código/repositórios transferidos ou archived (se contractor desenvolveu) \n - Documentação entregue e versionada \n - Laptop/hardware retornado, wiped, e certificação de limpeza \n - Secrets (API keys, passwords) rotacionados \n- [ ] Last backup de trabalho do contractor realizado (ex.: clone de repos privados) \n- [ ] Sign-off formal de \"offboarding completo\" registado em GRC com timestamp \n- [ ] Reminder legal enviado ao contractor: Confidentiality obligations continuam pós-término (duração, consequências) \n- [ ] Relatório de offboarding arquivado por 7 anos (DORA requirement) \n\n:::\n\n**Artefactos & evidências.** Checklist de offboarding preenchido, Confirmação de desativação de acesso, Backup certificate, Ativos recuperados (inventory), Sign-off GRC, Legal notice, Relatório arquivado\n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Obrigatório | Obrigatório + audit trail |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Operação | Data de término conhecida (programado), Rescisão imediata (unscheduled) | DevOps / SRE (acesso técnico) + AppSec Engineer (validação) + Security Champion (coordenação timeline HR; checkpoints) | Offboarding completo em **`<`24h** da data de termo; Notificação: HR envia aviso 2 semanas antes |\n| Validação | Data de término conhecida (programado), Rescisão imediata (unscheduled) | DevOps / SRE (acesso técnico) + AppSec Engineer (validação) + Security Champion (coordenação timeline HR; checkpoints) | Offboarding completo em **`<`24h** da data de termo; Notificação: HR envia aviso 2 semanas antes |\n\n**Ligações úteis.** \n- [Reavaliação de Fornecedores - US-14](#us-14---reavaliação-contínua-e-rotação-de-fornecedores-pós-onboarding) \n- [Preparação Técnica - US-15](#us-15---preparação-técnica-e-validação-de-contractors-pré-acesso) \n- [Checklist de Offboarding](/sbd-toe/sbd-manual/governanca-contratacao/addon/checklist-offboarding) \n\n---", "title": "US-17 - Offboarding Seguro de Contractors e Rescisão de Fornecedores", "traceability": {"line_end": 746, "line_start": 694, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-17-offboarding-seguro-de-contractors-e-rescisao-de-fornecedores"}, "vector_text": "US-17 - Offboarding Seguro de Contractors e Rescisão de Fornecedores\n\n### US-17 - Offboarding Seguro de Contractors e Rescisão de Fornecedores\n**Contexto.** Contractors terminam projeto ou contrato sem processo formal: acesso mantém-se ativo, ativos (código, credenciais, documentos) não são recuperados. Risco de vazamento pós-rescisão, acesso residual, violação de confidencialidade.\n\n:::userstory\n**História.** \nComo **Security Champion (HR) + DevOps / SRE**, quero **executar processo formal e automático de offboarding seguro quando contractor termina ou fornecedor é rescindido**, para **garantir que acesso é revogado completamente, ativos recuperados, confidencialidade mantida, e conformidade legal assegurada**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um contractor cuja data de termo é conhecida (ou fornecedor rescindido com aviso) \n **Quando** data de offboarding chega \n **Então** acesso é revogado, ativos recuperados, e conclusão documentada \n\n**Critérios de aceitação (DoD).** \n- [ ] Checklist de offboarding preparado 2 semanas antes (DevOps / SRE, Security Champion, AppSec Engineer, Scrum Master / Team Lead) \n- [ ] Notificação formal enviada ao contractor/fornecedor com data exata de desativação \n- [ ] Acesso a sistemas revogado (no máximo 24h após data de termo): \n - Contas de utilizador desativadas em Git, Jira, CI/CD \n - SSH keys e API tokens removidos \n - VPN, cloud IAM access revogado \n - MFA removido \n - Emails corporativos desativados (se aplicável) \n- [ ] Ativos recuperados: \n - Código/repositórios transferidos ou archived (se contractor desenvolveu) \n - Documentação entregue e versionada \n - Laptop/hardware retornado, wiped, e certificação de limpeza \n - Secrets (API keys, passwords) rotacionados \n- [ ] Last backup de trabalho do contractor realizado (ex.: clone de repos privados) \n- [ ] Sign-off formal de \"offboarding completo\" registado em GRC com timestamp \n- [ ] Reminder legal enviado ao contractor: Confidentiality obligations continuam pós-término (duração, consequências) \n- [ ] Relatório de offboarding arquivado por 7 anos (DORA requirement) \n\n:::\n\n**Artefactos & evidências.** Checklist de offboarding preenchido, Confirmação de desativação de acesso, Backup certificate, Ativos recuperados (inventory), Sign-off GRC, Legal notice, Relatório arquivado\n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Básico | Obrigatório | Obrigatório + audit trail |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Operação | Data de término conhecida (programado), Rescisão imediata (unscheduled) | DevOps / SRE (acesso técnico) + AppSec Engineer (validação) + Security Champion (coordenação timeline HR; checkpoints) | Offboarding completo em **`<`24h** da data de termo; Notificação: HR envia aviso 2 semanas antes |\n| Validação | Data de término conhecida (programado), Rescisão imediata (unscheduled) | DevOps / SRE (acesso técnico) + AppSec Engineer (validação) + Security Champion (coordenação timeline HR; checkpoints) | Offboarding completo em **`<`24h** da data de termo; Notificação: HR envia aviso 2 semanas antes |\n\n**Ligações úteis.** \n- [Reavaliação de Fornecedores - US-14](#us-14---reavaliação-contínua-e-rotação-de-fornecedores-pós-onboarding) \n- [Preparação Técnica - US-15](#us-15---preparação-técnica-e-validação-de-contractors-pré-acesso) \n- [Checklist de Offboarding](/sbd-toe/sbd-manual/governanca-contratacao/addon/checklist-offboarding) \n\n---"}
|
|
3701
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-18-monitorizacao-continua-de-conformidade-de-fornecedores-alertas-e-escalacao", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-14", "US-18"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-18-monitorizacao-continua-de-conformidade-de-fornecedores-alertas-e-escalacao", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-18 - Monitorização Contínua de Conformidade de Fornecedores (Alertas e Escalação)"], "size_estimate": {"approx_tokens": 754, "chars": 3013}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-18 - Monitorização Contínua de Conformidade de Fornecedores (Alertas e Escalação)\n**Contexto.** Fornecedores são avaliados periodicamente (US-14), mas risco entre ciclos não é detetado. CVEs, incidentes críticos, mudanças de SLA, ou breaches não são monitorados em tempo real.\n\n:::userstory\n**História.** \nComo **AppSec Engineer + Operações (Ops)**, quero **monitorizar continuamente conformidade de fornecedores críticos (incidentes, CVEs, SLA, mudanças organizacionais) e escalar automaticamente se gaps surgem**, para **reduzir risco residual entre ciclos de avaliação formal e detetar eventos críticos em tempo real**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um fornecedor crítico (L2–L3) com contrato vigente \n **Quando** incidente, CVE crítico, SLA breach, ou mudança organizacional é reportado \n **Então** alerta automático é gerado e escalado para AppSec e Procurement \n\n**Critérios de aceitação (DoD).** \n- [ ] Integração com feed de incidentes do fornecedor (status page, email alerts, API) \n- [ ] Monitorização contínua de CVEs em stack técnico do fornecedor (via SBOM/SCA tool) \n- [ ] Alerta automático acionado se: \n - CVE crítico em dependência do fornecedor não mitigado em 72h (L3) ou 7 dias (L2) \n - Incidente de segurança reportado pelo fornecedor \n - SLA não cumprido (ex.: uptime `<`99.5% para L3, `<`99% para L2) \n - Mudança de propriedade, localização, ou subcontratação \n- [ ] Escalação automática com prioridade: \n - **P0 (CVE crítico explorado):** Immediate → AppSec Engineer + GRC / Compliance (Procurement Officer) + CISO \n - **P1 (CVE crítico, incidente grave):** 1h → AppSec Engineer + GRC / Compliance (Procurement Officer) \n - **P2 (CVE high, incidente moderado):** 4h → AppSec Engineer \n- [ ] Trigger automático de revisão especial fora-de-ciclo (US-14) se gap crítico \n- [ ] Registo de alerta, escalonamento, e ação documentado em GRC (audit trail) \n- [ ] Dashboard em tempo real com status de fornecedores críticos e alertas ativas (visível a board) \n\n:::\n\n**Artefactos & evidências.** Feed de incidentes configurado, CVE monitoring ativo, Alertas documentados com timestamps, Escalation records, Dashboard, GRC audit trail\n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Não | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Operação | Incidente, CVE crítico, SLA breach, mudança contratual | AppSec Engineer (setup inicial) + Operações (Ops) (operação 24x7) | Alerta em **`<`1h** de deteção, escalonamento em `<`15 min |\n\n**Ligações úteis.** \n- [Reavaliação de Fornecedores - US-14](#us-14---reavaliação-contínua-e-rotação-de-fornecedores-pós-onboarding) \n- [Monitorização - Cap. 12](/sbd-toe/sbd-manual/monitorizacao-operacoes/aplicacao-lifecycle) \n- [Dependências e SCA - Cap. 05](/sbd-toe/sbd-manual/dependencias-sbom-sca/aplicacao-lifecycle) \n\n---", "title": "US-18 - Monitorização Contínua de Conformidade de Fornecedores (Alertas e Escalação)", "traceability": {"line_end": 795, "line_start": 747, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-18-monitorizacao-continua-de-conformidade-de-fornecedores-alertas-e-escalacao"}, "vector_text": "US-18 - Monitorização Contínua de Conformidade de Fornecedores (Alertas e Escalação)\n\n### US-18 - Monitorização Contínua de Conformidade de Fornecedores (Alertas e Escalação)\n**Contexto.** Fornecedores são avaliados periodicamente (US-14), mas risco entre ciclos não é detetado. CVEs, incidentes críticos, mudanças de SLA, ou breaches não são monitorados em tempo real.\n\n:::userstory\n**História.** \nComo **AppSec Engineer + Operações (Ops)**, quero **monitorizar continuamente conformidade de fornecedores críticos (incidentes, CVEs, SLA, mudanças organizacionais) e escalar automaticamente se gaps surgem**, para **reduzir risco residual entre ciclos de avaliação formal e detetar eventos críticos em tempo real**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um fornecedor crítico (L2–L3) com contrato vigente \n **Quando** incidente, CVE crítico, SLA breach, ou mudança organizacional é reportado \n **Então** alerta automático é gerado e escalado para AppSec e Procurement \n\n**Critérios de aceitação (DoD).** \n- [ ] Integração com feed de incidentes do fornecedor (status page, email alerts, API) \n- [ ] Monitorização contínua de CVEs em stack técnico do fornecedor (via SBOM/SCA tool) \n- [ ] Alerta automático acionado se: \n - CVE crítico em dependência do fornecedor não mitigado em 72h (L3) ou 7 dias (L2) \n - Incidente de segurança reportado pelo fornecedor \n - SLA não cumprido (ex.: uptime `<`99.5% para L3, `<`99% para L2) \n - Mudança de propriedade, localização, ou subcontratação \n- [ ] Escalação automática com prioridade: \n - **P0 (CVE crítico explorado):** Immediate → AppSec Engineer + GRC / Compliance (Procurement Officer) + CISO \n - **P1 (CVE crítico, incidente grave):** 1h → AppSec Engineer + GRC / Compliance (Procurement Officer) \n - **P2 (CVE high, incidente moderado):** 4h → AppSec Engineer \n- [ ] Trigger automático de revisão especial fora-de-ciclo (US-14) se gap crítico \n- [ ] Registo de alerta, escalonamento, e ação documentado em GRC (audit trail) \n- [ ] Dashboard em tempo real com status de fornecedores críticos e alertas ativas (visível a board) \n\n:::\n\n**Artefactos & evidências.** Feed de incidentes configurado, CVE monitoring ativo, Alertas documentados com timestamps, Escalation records, Dashboard, GRC audit trail\n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Não | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Operação | Incidente, CVE crítico, SLA breach, mudança contratual | AppSec Engineer (setup inicial) + Operações (Ops) (operação 24x7) | Alerta em **`<`1h** de deteção, escalonamento em `<`15 min |\n\n**Ligações úteis.** \n- [Reavaliação de Fornecedores - US-14](#us-14---reavaliação-contínua-e-rotação-de-fornecedores-pós-onboarding) \n- [Monitorização - Cap. 12](/sbd-toe/sbd-manual/monitorizacao-operacoes/aplicacao-lifecycle) \n- [Dependências e SCA - Cap. 05](/sbd-toe/sbd-manual/dependencias-sbom-sca/aplicacao-lifecycle) \n\n---"}
|
|
3702
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-19-revisao-trimestral-de-acesso-de-contractors-least-privilege", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": ["governance-and-procurement"], "phase": ["govern"], "risk_level": ["L1", "L2", "L3"]}, "mentioned_entities": {"Requirement": ["GOV-014"], "UserStory": ["US-15", "US-17", "US-19"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-19-revisao-trimestral-de-acesso-de-contractors-least-privilege", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-19 - Revisão Trimestral de Acesso de Contractors (Least Privilege)"], "size_estimate": {"approx_tokens": 735, "chars": 2938}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-19 - Revisão Trimestral de Acesso de Contractors (Least Privilege)\n**Contexto.** Contractors ganham acesso inicial, mas permissões acumulam ao longo do tempo (\"acesso creep\"). Sem revisão periódica, principle of least privilege é violado.\n\n:::userstory\n**História.** \nComo **Security Champion + DevOps / SRE + Scrum Master / Team Lead**, quero **revisar trimestralmente acesso de contractors em ativo, validando que têm apenas acesso necessário ao projeto**, para **manter principle of least privilege, reduzir risco de acesso excessivo, e remover acesso obsoleto**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** contractors ativos com acesso a sistemas (repos, CI/CD, databases, cloud) \n **Quando** ciclo trimestral de revisão chega \n **Então** acesso é validado com Scrum Master / Team Lead, e acesso excessivo é removido no mesmo dia \n\n**Critérios de aceitação (DoD).** \n- [ ] Lista de contractors ativos extraída de sistemas (Git orgs, Jira, VPN, Cloud IAM, databases) \n- [ ] Por cada contractor: \n - Acesso listado em detalhe (repositórios, CI/CD pipelines, databases, cloud resources, etc.) \n - Scrum Master / Team Lead valida cada acesso: **Necessário para projeto atual?** (Sim/Não/Modificar) \n - Se **Não necessário:** acesso removido no mesmo dia \n - Se **Modificar:** novo scope configurado, antigo revogado \n - Se **Sim:** mantém-se com confirmação datada \n- [ ] Checklist de revisão preenchido e assinado digitalmente por Scrum Master / Team Lead + Security Champion \n- [ ] Notificação enviada a cada contractor informando resultado da revisão \n- [ ] Se acesso removido: notificação clara indicando motivo e data de conclusão \n- [ ] Registo de mudanças documentado em audit trail (Git logs, IAM change log, etc.) \n- [ ] Relatório consolidado (% de acesso mantido, % removido) entregue ao AppSec Engineer \n\n:::\n\n**Artefactos & evidências.** Lista de contractors e acesso, Checklist assinado, Notificações enviadas, Git/IAM logs de mudanças, Relatório consolidado, Sign-off\n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Semestral | Trimestral | Trimestral |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Validação | Calendário (trimestral), Mudança de projeto, Incidente | Security Champion (coordenação) + Scrum Master / Team Lead (validação de necessidade) + DevOps / SRE (mudanças técnicas) | Revisão iniciada e completada em **1 semana** |\n\n**Ligações úteis.** \n- [Preparação Técnica - US-15](#us-15---preparação-técnica-e-validação-de-contractors-pré-acesso) \n- [Offboarding - US-17](#us-17---offboarding-seguro-de-contractors-e-rescisão-de-fornecedores) \n- [Requisitos de Autenticação e Acesso - Cap. 02](/sbd-toe/sbd-manual/requisitos-seguranca/aplicacao-lifecycle) \n- Grounding canónico: [`GOV-014`](./addon/catalogo-requisitos-governanca) \n\n---", "title": "US-19 - Revisão Trimestral de Acesso de Contractors (Least Privilege)", "traceability": {"line_end": 843, "line_start": 796, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-19-revisao-trimestral-de-acesso-de-contractors-least-privilege"}, "vector_text": "US-19 - Revisão Trimestral de Acesso de Contractors (Least Privilege)\n\n### US-19 - Revisão Trimestral de Acesso de Contractors (Least Privilege)\n**Contexto.** Contractors ganham acesso inicial, mas permissões acumulam ao longo do tempo (\"acesso creep\"). Sem revisão periódica, principle of least privilege é violado.\n\n:::userstory\n**História.** \nComo **Security Champion + DevOps / SRE + Scrum Master / Team Lead**, quero **revisar trimestralmente acesso de contractors em ativo, validando que têm apenas acesso necessário ao projeto**, para **manter principle of least privilege, reduzir risco de acesso excessivo, e remover acesso obsoleto**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** contractors ativos com acesso a sistemas (repos, CI/CD, databases, cloud) \n **Quando** ciclo trimestral de revisão chega \n **Então** acesso é validado com Scrum Master / Team Lead, e acesso excessivo é removido no mesmo dia \n\n**Critérios de aceitação (DoD).** \n- [ ] Lista de contractors ativos extraída de sistemas (Git orgs, Jira, VPN, Cloud IAM, databases) \n- [ ] Por cada contractor: \n - Acesso listado em detalhe (repositórios, CI/CD pipelines, databases, cloud resources, etc.) \n - Scrum Master / Team Lead valida cada acesso: **Necessário para projeto atual?** (Sim/Não/Modificar) \n - Se **Não necessário:** acesso removido no mesmo dia \n - Se **Modificar:** novo scope configurado, antigo revogado \n - Se **Sim:** mantém-se com confirmação datada \n- [ ] Checklist de revisão preenchido e assinado digitalmente por Scrum Master / Team Lead + Security Champion \n- [ ] Notificação enviada a cada contractor informando resultado da revisão \n- [ ] Se acesso removido: notificação clara indicando motivo e data de conclusão \n- [ ] Registo de mudanças documentado em audit trail (Git logs, IAM change log, etc.) \n- [ ] Relatório consolidado (% de acesso mantido, % removido) entregue ao AppSec Engineer \n\n:::\n\n**Artefactos & evidências.** Lista de contractors e acesso, Checklist assinado, Notificações enviadas, Git/IAM logs de mudanças, Relatório consolidado, Sign-off\n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Semestral | Trimestral | Trimestral |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Validação | Calendário (trimestral), Mudança de projeto, Incidente | Security Champion (coordenação) + Scrum Master / Team Lead (validação de necessidade) + DevOps / SRE (mudanças técnicas) | Revisão iniciada e completada em **1 semana** |\n\n**Ligações úteis.** \n- [Preparação Técnica - US-15](#us-15---preparação-técnica-e-validação-de-contractors-pré-acesso) \n- [Offboarding - US-17](#us-17---offboarding-seguro-de-contractors-e-rescisão-de-fornecedores) \n- [Requisitos de Autenticação e Acesso - Cap. 02](/sbd-toe/sbd-manual/requisitos-seguranca/aplicacao-lifecycle) \n- Grounding canónico: [`GOV-014`](./addon/catalogo-requisitos-governanca) \n\n---"}
|
|
3703
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-20-feedback-pos-projeto-e-rating-de-contractors", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-09", "US-14", "US-17", "US-20"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-20-feedback-pos-projeto-e-rating-de-contractors", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-20 - Feedback Pós-Projeto e Rating de Contractors"], "size_estimate": {"approx_tokens": 709, "chars": 2836}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-20 - Feedback Pós-Projeto e Rating de Contractors\n**Contexto.** Contractors terminam projeto sem feedback sobre desempenho de segurança. Sem dados de avaliação, impossível tomar decisão informada sobre re-hire ou referência.\n\n:::userstory\n**História.** \nComo **Security Champion + Scrum Master / Team Lead**, quero **recolher feedback estruturado pós-projeto de contractors sobre compreensão de segurança, incidentes, e recomendações**, para **informar decisão de re-hire, melhorar programa de preparação, e criar base de dados de avaliação**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um contractor cujo projeto termina \n **Quando** offboarding é iniciado (US-17) \n **Então** feedback form é enviado para Scrum Master / Team Lead + AppSec Engineer preencherem \n\n**Critérios de aceitação (DoD).** \n- [ ] Feedback form criado com perguntas estruturadas: \n - **Segurança:** Compreensão de políticas (escala 1–5), Best practices aplicadas (Sim/Não), Incidentes durante projeto (Sim/Não + desc) \n - **Performance:** Qualidade de código (1–5), Teste (1–5), Documentação (1–5) \n - **Conformidade:** Contractor seguiu procedimentos obrigatórios (Sim/Não), Violações (Sim/Não + desc) \n - **Recomendações:** Áreas de melhoria em formação/preparação, Rating de segurança geral (1–5 stars) \n - **Decisão:** Re-hire recomendado? (Sim/Não/Talvez + justificação) \n- [ ] Feedback recolhido de Scrum Master / Team Lead + AppSec Engineer + Security Champion (consenso) \n- [ ] Resultado registado em sistema centralizado (HR, Procurement, GRC) com data e reviewers \n- [ ] Rating (positivo/neutro/negativo) armazenado como referência para futuras contratações \n- [ ] Se múltiplos contractors de mesmo fornecedor: insights agregados para revisão de fornecedor (US-14) \n- [ ] Resultados consolidados publicados em relatório trimestral de programa de contractors \n\n:::\n\n**Artefactos & evidências.** Feedback form preenchido, Ratings registados (sistema HR/GRC), Agregação por fornecedor, Relatório trimestral, Histórico de avaliações\n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Opcional | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Operação | Offboarding iniciado (US-17) | Security Champion (coordenação) + Scrum Master / Team Lead + AppSec Engineer (preenchimento) | Feedback completado em **3 dias úteis** após fim do contrato |\n\n**Ligações úteis.** \n- [Offboarding - US-17](#us-17---offboarding-seguro-de-contractors-e-rescisão-de-fornecedores) \n- [Reavaliação de Fornecedores - US-14](#us-14---reavaliação-contínua-e-rotação-de-fornecedores-pós-onboarding) \n- [Designação de Owners - US-09](#us-09---designação-formal-de-owners-de-segurança-por-aplicação) \n\n---", "title": "US-20 - Feedback Pós-Projeto e Rating de Contractors", "traceability": {"line_end": 889, "line_start": 844, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-20-feedback-pos-projeto-e-rating-de-contractors"}, "vector_text": "US-20 - Feedback Pós-Projeto e Rating de Contractors\n\n### US-20 - Feedback Pós-Projeto e Rating de Contractors\n**Contexto.** Contractors terminam projeto sem feedback sobre desempenho de segurança. Sem dados de avaliação, impossível tomar decisão informada sobre re-hire ou referência.\n\n:::userstory\n**História.** \nComo **Security Champion + Scrum Master / Team Lead**, quero **recolher feedback estruturado pós-projeto de contractors sobre compreensão de segurança, incidentes, e recomendações**, para **informar decisão de re-hire, melhorar programa de preparação, e criar base de dados de avaliação**.\n\n**Critérios de aceitação (BDD).** \n- **Dado** um contractor cujo projeto termina \n **Quando** offboarding é iniciado (US-17) \n **Então** feedback form é enviado para Scrum Master / Team Lead + AppSec Engineer preencherem \n\n**Critérios de aceitação (DoD).** \n- [ ] Feedback form criado com perguntas estruturadas: \n - **Segurança:** Compreensão de políticas (escala 1–5), Best practices aplicadas (Sim/Não), Incidentes durante projeto (Sim/Não + desc) \n - **Performance:** Qualidade de código (1–5), Teste (1–5), Documentação (1–5) \n - **Conformidade:** Contractor seguiu procedimentos obrigatórios (Sim/Não), Violações (Sim/Não + desc) \n - **Recomendações:** Áreas de melhoria em formação/preparação, Rating de segurança geral (1–5 stars) \n - **Decisão:** Re-hire recomendado? (Sim/Não/Talvez + justificação) \n- [ ] Feedback recolhido de Scrum Master / Team Lead + AppSec Engineer + Security Champion (consenso) \n- [ ] Resultado registado em sistema centralizado (HR, Procurement, GRC) com data e reviewers \n- [ ] Rating (positivo/neutro/negativo) armazenado como referência para futuras contratações \n- [ ] Se múltiplos contractors de mesmo fornecedor: insights agregados para revisão de fornecedor (US-14) \n- [ ] Resultados consolidados publicados em relatório trimestral de programa de contractors \n\n:::\n\n**Artefactos & evidências.** Feedback form preenchido, Ratings registados (sistema HR/GRC), Agregação por fornecedor, Relatório trimestral, Histórico de avaliações\n\n**Proporcionalidade.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Opcional | Recomendado | Obrigatório |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Operação | Offboarding iniciado (US-17) | Security Champion (coordenação) + Scrum Master / Team Lead + AppSec Engineer (preenchimento) | Feedback completado em **3 dias úteis** após fim do contrato |\n\n**Ligações úteis.** \n- [Offboarding - US-17](#us-17---offboarding-seguro-de-contractors-e-rescisão-de-fornecedores) \n- [Reavaliação de Fornecedores - US-14](#us-14---reavaliação-contínua-e-rotação-de-fornecedores-pós-onboarding) \n- [Designação de Owners - US-09](#us-09---designação-formal-de-owners-de-segurança-por-aplicação) \n\n---"}
|
|
3704
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-21-contratacao-de-provedores-de-modelos-ai-us-21", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": ["dependencies-sbom-sca"], "phase": ["govern"], "risk_level": ["L2", "L3"]}, "mentioned_entities": {"Requirement": ["DEP-014"], "UserStory": ["US-14", "US-21"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-21-contratacao-de-provedores-de-modelos-ai-us-21", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-21 - Contratação de provedores de modelos AI {#us-21}"], "size_estimate": {"approx_tokens": 1326, "chars": 5301}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-21 - Contratação de provedores de modelos AI {#us-21}\n\n**Contexto.**\nA US-14 cobre reavaliação contínua de fornecedores em geral. Quando o fornecedor é um **provedor de modelos AI** (Anthropic, OpenAI, Google, Mistral, Cohere, HuggingFace, providers próprios *self-hosted*), surgem cláusulas que os contratos tradicionais não cobriam: *data retention*, *training opt-out*, localização de processamento (RGPD), audit rights sobre logs de inferência, SLA de notificação de mudanças de versão, conformidade declarada com AI Act Art. 53/55 quando o provedor fornece GPAI. Esta US operacionaliza esses requisitos contratuais antes de o provedor entrar na lista aprovada (cross-link [`DEP-014`](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/catalogo-requisitos-dependencias#dep-014)).\n\n:::userstory\n**História.**\nComo **GRC / Compliance (Procurement + Legal)**, quero que cada contrato com provedor de modelos AI inclua cláusulas mínimas que cubram tratamento de dados, localização, *audit rights*, notificação de mudanças e conformidade regulatória aplicável, para que o uso operacional do provedor seja sustentável jurídica e tecnicamente.\n\n**Critérios de aceitação (BDD).**\n- **Dado** que se pretende adoptar um novo provedor AI para uso operacional\n **Quando** se iniciam as diligências contratuais\n **Então** a *due diligence* (cross-link Policy 33 §3) é estendida com os critérios específicos AI: data retention, training opt-out, localização (RGPD Art. 44–49), audit rights, SLA de notificação, AI Act Art. 53/55 quando GPAI\n- **Dado** que o contrato é finalizado\n **Quando** o provedor é adicionado à lista aprovada ([`DEP-014`](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/catalogo-requisitos-dependencias#dep-014))\n **Então** o `contract_ref` referencia o contrato vigente e regista cláusulas críticas\n- **Dado** que o provedor altera modelo de dados (e.g. nova política de training) ou versão maior do modelo\n **Quando** é notificado conforme SLA contratual\n **Então** corre revisão (`appsec` + `grc`) antes do *cutover*; sem notificação adequada, dispara revisão proactiva\n\n**Checklist.**\n- [ ] *Data retention*: declarada (preferência zero retention para dados sensíveis); compatível com a classificação de dados que o sistema envia\n- [ ] *Training opt-out*: contratualizado quando aplicável; declarado quando \"opt-out por defeito\"\n- [ ] **Localização de processamento**: documentada; conforme RGPD Art. 44–49 quando há dados pessoais; cláusulas para *international transfers* quando aplicável\n- [ ] **Audit rights**: acesso contratualizado a logs de inferência ou equivalente quando exigido (típico em L3)\n- [ ] **SLA de notificação prévia** de mudanças que alterem comportamento (versão maior do modelo, política de dados, descontinuação)\n- [ ] **SLA de disponibilidade** declarado; *fallback* arquitectónico em caso de *outage* (cross-link Cap. 04 §AI/ML)\n- [ ] **Conformidade declarada com AI Act Art. 53/55** quando o provedor fornece GPAI\n- [ ] **Conformidade declarada com RGPD Art. 28** (sub-processadores) quando há dados pessoais\n- [ ] Provedor incluído na lista aprovada ([`DEP-014`](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/catalogo-requisitos-dependencias#dep-014)) com `risk_classification`\n- [ ] Cláusulas críticas registadas na ficha do provedor; revisão calendarizada\n\n:::\n\n**🧾 Artefactos & evidências.**\n- Contrato assinado com cláusulas explícitas (referenciado em `contract_ref` da lista aprovada)\n- Ficha do provedor no repositório de governança (`governance/ai-providers/<provider>.md`) com cláusulas críticas\n- Registo de notificações recebidas do provedor + acções tomadas\n- Revisão periódica documentada conforme nível de risco\n\n**⚖️ Proporcionalidade.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Recomendado | Cláusulas mínimas: localização + zero retention para dados sensíveis |\n| L2 | Sim | Cláusulas detalhadas: retention, opt-out, localização, SLA, audit rights básico |\n| L3 | Sim | Cláusulas detalhadas + audit rights operacionais + AI Act Art. 53/55 quando GPAI; revisão Legal obrigatória |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Pré-onboarding | Adopção de novo provedor AI | GRC / Compliance (Procurement + Legal) | Antes do uso operacional |\n| Operação | Notificação de mudança pelo provedor | AppSec Engineer + GRC / Compliance | Conforme SLA contratual; pré-*cutover* |\n| Revisão periódica | Cadência por nível de risco | GRC / Compliance | L1 anual / L2 semestral / L3 trimestral |\n| Descontinuação | Provider removido da lista | GRC / Compliance + DevOps / SRE | Plano de migração antes da remoção operacional |\n\n**Ligações úteis.**\n- 🔗 [`DEP-014` — Lista de providers AI aprovados](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/catalogo-requisitos-dependencias#dep-014)\n- 🔗 [US-14 do Cap. 05 — AI BOM](/sbd-toe/sbd-manual/dependencias-sbom-sca/aplicacao-lifecycle)\n- 🔗 [Policy 33 — Contratação Segura (anexo AI providers)](/sbd-toe/assets/policies/policy-contratacao-segura)\n- 🔗 [Policy 39 — AI BOM e Supply Chain](/sbd-toe/assets/policies/policy-ai-bom-supply-chain)\n- 🔗 [Cross-check AI Act](/sbd-toe/cross-check-normativo/ai-act/intro)\n- 🔗 [Cross-check RGPD](/sbd-toe/cross-check-normativo/gdpr/intro)\n\n---", "title": "US-21 - Contratação de provedores de modelos AI {#us-21}", "traceability": {"line_end": 954, "line_start": 890, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-21-contratacao-de-provedores-de-modelos-ai-us-21"}, "vector_text": "US-21 - Contratação de provedores de modelos AI {#us-21}\n\n### US-21 - Contratação de provedores de modelos AI {#us-21}\n\n**Contexto.**\nA US-14 cobre reavaliação contínua de fornecedores em geral. Quando o fornecedor é um **provedor de modelos AI** (Anthropic, OpenAI, Google, Mistral, Cohere, HuggingFace, providers próprios *self-hosted*), surgem cláusulas que os contratos tradicionais não cobriam: *data retention*, *training opt-out*, localização de processamento (RGPD), audit rights sobre logs de inferência, SLA de notificação de mudanças de versão, conformidade declarada com AI Act Art. 53/55 quando o provedor fornece GPAI. Esta US operacionaliza esses requisitos contratuais antes de o provedor entrar na lista aprovada (cross-link [`DEP-014`](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/catalogo-requisitos-dependencias#dep-014)).\n\n:::userstory\n**História.**\nComo **GRC / Compliance (Procurement + Legal)**, quero que cada contrato com provedor de modelos AI inclua cláusulas mínimas que cubram tratamento de dados, localização, *audit rights*, notificação de mudanças e conformidade regulatória aplicável, para que o uso operacional do provedor seja sustentável jurídica e tecnicamente.\n\n**Critérios de aceitação (BDD).**\n- **Dado** que se pretende adoptar um novo provedor AI para uso operacional\n **Quando** se iniciam as diligências contratuais\n **Então** a *due diligence* (cross-link Policy 33 §3) é estendida com os critérios específicos AI: data retention, training opt-out, localização (RGPD Art. 44–49), audit rights, SLA de notificação, AI Act Art. 53/55 quando GPAI\n- **Dado** que o contrato é finalizado\n **Quando** o provedor é adicionado à lista aprovada ([`DEP-014`](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/catalogo-requisitos-dependencias#dep-014))\n **Então** o `contract_ref` referencia o contrato vigente e regista cláusulas críticas\n- **Dado** que o provedor altera modelo de dados (e.g. nova política de training) ou versão maior do modelo\n **Quando** é notificado conforme SLA contratual\n **Então** corre revisão (`appsec` + `grc`) antes do *cutover*; sem notificação adequada, dispara revisão proactiva\n\n**Checklist.**\n- [ ] *Data retention*: declarada (preferência zero retention para dados sensíveis); compatível com a classificação de dados que o sistema envia\n- [ ] *Training opt-out*: contratualizado quando aplicável; declarado quando \"opt-out por defeito\"\n- [ ] **Localização de processamento**: documentada; conforme RGPD Art. 44–49 quando há dados pessoais; cláusulas para *international transfers* quando aplicável\n- [ ] **Audit rights**: acesso contratualizado a logs de inferência ou equivalente quando exigido (típico em L3)\n- [ ] **SLA de notificação prévia** de mudanças que alterem comportamento (versão maior do modelo, política de dados, descontinuação)\n- [ ] **SLA de disponibilidade** declarado; *fallback* arquitectónico em caso de *outage* (cross-link Cap. 04 §AI/ML)\n- [ ] **Conformidade declarada com AI Act Art. 53/55** quando o provedor fornece GPAI\n- [ ] **Conformidade declarada com RGPD Art. 28** (sub-processadores) quando há dados pessoais\n- [ ] Provedor incluído na lista aprovada ([`DEP-014`](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/catalogo-requisitos-dependencias#dep-014)) com `risk_classification`\n- [ ] Cláusulas críticas registadas na ficha do provedor; revisão calendarizada\n\n:::\n\n**🧾 Artefactos & evidências.**\n- Contrato assinado com cláusulas explícitas (referenciado em `contract_ref` da lista aprovada)\n- Ficha do provedor no repositório de governança (`governance/ai-providers/<provider>.md`) com cláusulas críticas\n- Registo de notificações recebidas do provedor + acções tomadas\n- Revisão periódica documentada conforme nível de risco\n\n**⚖️ Proporcionalidade.**\n| Nível | Obrigatório? | Ajustes |\n|---|---|---|\n| L1 | Recomendado | Cláusulas mínimas: localização + zero retention para dados sensíveis |\n| L2 | Sim | Cláusulas detalhadas: retention, opt-out, localização, SLA, audit rights básico |\n| L3 | Sim | Cláusulas detalhadas + audit rights operacionais + AI Act Art. 53/55 quando GPAI; revisão Legal obrigatória |\n\n**Integração no SDLC.**\n| Fase | Trigger | Responsável | SLA |\n|---|---|---|---|\n| Pré-onboarding | Adopção de novo provedor AI | GRC / Compliance (Procurement + Legal) | Antes do uso operacional |\n| Operação | Notificação de mudança pelo provedor | AppSec Engineer + GRC / Compliance | Conforme SLA contratual; pré-*cutover* |\n| Revisão periódica | Cadência por nível de risco | GRC / Compliance | L1 anual / L2 semestral / L3 trimestral |\n| Descontinuação | Provider removido da lista | GRC / Compliance + DevOps / SRE | Plano de migração antes da remoção operacional |\n\n**Ligações úteis.**\n- 🔗 [`DEP-014` — Lista de providers AI aprovados](/sbd-toe/sbd-manual/dependencias-sbom-sca/addon/catalogo-requisitos-dependencias#dep-014)\n- 🔗 [US-14 do Cap. 05 — AI BOM](/sbd-toe/sbd-manual/dependencias-sbom-sca/aplicacao-lifecycle)\n- 🔗 [Policy 33 — Contratação Segura (anexo AI providers)](/sbd-toe/assets/policies/policy-contratacao-segura)\n- 🔗 [Policy 39 — AI BOM e Supply Chain](/sbd-toe/assets/policies/policy-ai-bom-supply-chain)\n- 🔗 [Cross-check AI Act](/sbd-toe/cross-check-normativo/ai-act/intro)\n- 🔗 [Cross-check RGPD](/sbd-toe/cross-check-normativo/gdpr/intro)\n\n---"}
|
|
3705
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-22-aprovacao-formal-e-auditoria-periodica-das-politicas-organizacionais-us-22", "chunk_kind": "user_story", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "user_story", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-12", "US-22"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-22-aprovacao-formal-e-auditoria-periodica-das-politicas-organizacionais-us-22", "relation_hints": ["practice_has_user_story"], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📊 Matriz de Rastreabilidade Global", "US-22 - Aprovação formal e auditoria periódica das políticas organizacionais {#us-22}"], "size_estimate": {"approx_tokens": 1037, "chars": 4148}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "### US-22 - Aprovação formal e auditoria periódica das políticas organizacionais {#us-22}\n\nUma política não aprovada pela direção não tem autoridade; uma política não auditada perde aderência ao longo do tempo. \n\n**Contexto.** O capítulo prescreve um conjunto de políticas organizacionais relevantes (gestão de exceções, contratação segura, rastreabilidade organizacional, auditoria de fornecedores, KPIs de governação — ver intro §Políticas Organizacionais Relevantes) e o checklist canónico exige que estas estejam *formalmente aprovadas e auditadas*. A US-12 formaliza a política do **modelo de governação**, mas o restante corpo de políticas fica sem uma user story que operacionalize o seu ciclo de aprovação pela direção e de auditoria periódica. Sem este ciclo, as políticas existem como documento mas não como controlo vivo: ninguém confirma que continuam aprovadas, atualizadas e cumpridas. \n\n:::userstory\n**História.** \nComo **GRC / Compliance** com apoio de **CISO + Gestão Executiva**, quero **manter cada política organizacional do capítulo num ciclo formal de aprovação pela direção e de auditoria periódica de aderência**, para **garantir que o corpo de políticas tem autoridade, está atualizado e é efetivamente cumprido e auditável**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** uma política organizacional relevante (exceções, contratação segura, rastreabilidade, auditoria de fornecedores, KPIs de governação) \n **Quando** é criada ou revista \n **Então** é submetida a aprovação formal da direção, com versão, data e aprovador registados antes de entrar em vigor \n- **Dado** uma política em vigor \n **Quando** chega o ciclo de auditoria definido (no máximo anual) \n **Então** é auditada a aderência prática, registam-se desvios e gera-se ação corretiva com owner e prazo \n\n**Checklist.** \n- [ ] Inventário das políticas organizacionais relevantes do capítulo mantido e versionado, com estado (Obrigatória/Recomendado), owner e data da última aprovação \n- [ ] Cada política tem aprovação formal da direção registada (versão, data, aprovador) antes de entrar em vigor; revisão pelo menos anual ou após mudança organizacional significativa \n- [ ] Auditoria periódica de aderência executada por ciclo definido, com desvios registados e ações corretivas (owner + prazo) acompanhadas até fecho \n\n:::\n\n**Artefactos & evidências.** Inventário versionado de políticas com estado e owner; registo de aprovação formal pela direção (versão/data/aprovador); relatório de auditoria de aderência por ciclo; plano de ações corretivas para desvios. \n\n**Proporcionalidade L1–L3.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Políticas obrigatórias aprovadas; auditoria informal anual | Conjunto completo aprovado; auditoria formal anual com registo de desvios | Conjunto completo aprovado; auditoria formal ≤ anual + revisão por mudança organizacional; ações corretivas rastreadas até fecho |\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|------|---------|-------------|-----|\n| Planeamento | Criação ou revisão de política | GRC / Compliance + CISO + Gestão Executiva (aprovação) | Aprovação antes da entrada em vigor |\n| Auditoria | Ciclo periódico (≤ anual) ou mudança organizacional | GRC / Compliance + AppSec Engineer | Auditoria concluída no ciclo; ações corretivas com prazo definido |\n\n**Ligações úteis.** \n- [Checklist de Revisão Periódica — Governança e Contratação](/sbd-toe/sbd-manual/governanca-contratacao/canon/checklist-revisao)\n- [Modelo formal de governação — US-12](#us-12---formalização-de-modelo-de-governação-por-nível-de-risco)\n- [Processo Canónico de Gestão de Exceções](./addon/processo-excecoes)\n- [Política de Gestão de Exceções de Segurança](/sbd-toe/assets/policies/policy-gestao-excecoes)\n- [Política de Contratação Segura](/sbd-toe/assets/policies/policy-contratacao-segura)\n- [Política de Rastreabilidade Organizacional](/sbd-toe/assets/policies/policy-rastreabilidade-organizacional)\n- [Política de KPIs de Governação de Segurança](/sbd-toe/assets/policies/policy-kpis-governacao)\n\n---", "title": "US-22 - Aprovação formal e auditoria periódica das políticas organizacionais {#us-22}", "traceability": {"line_end": 1003, "line_start": 955, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-rastreabilidade-global--us-22-aprovacao-formal-e-auditoria-periodica-das-politicas-organizacionais-us-22"}, "vector_text": "US-22 - Aprovação formal e auditoria periódica das políticas organizacionais {#us-22}\n\n### US-22 - Aprovação formal e auditoria periódica das políticas organizacionais {#us-22}\n\nUma política não aprovada pela direção não tem autoridade; uma política não auditada perde aderência ao longo do tempo. \n\n**Contexto.** O capítulo prescreve um conjunto de políticas organizacionais relevantes (gestão de exceções, contratação segura, rastreabilidade organizacional, auditoria de fornecedores, KPIs de governação — ver intro §Políticas Organizacionais Relevantes) e o checklist canónico exige que estas estejam *formalmente aprovadas e auditadas*. A US-12 formaliza a política do **modelo de governação**, mas o restante corpo de políticas fica sem uma user story que operacionalize o seu ciclo de aprovação pela direção e de auditoria periódica. Sem este ciclo, as políticas existem como documento mas não como controlo vivo: ninguém confirma que continuam aprovadas, atualizadas e cumpridas. \n\n:::userstory\n**História.** \nComo **GRC / Compliance** com apoio de **CISO + Gestão Executiva**, quero **manter cada política organizacional do capítulo num ciclo formal de aprovação pela direção e de auditoria periódica de aderência**, para **garantir que o corpo de políticas tem autoridade, está atualizado e é efetivamente cumprido e auditável**. \n\n**Critérios de aceitação (BDD).** \n- **Dado** uma política organizacional relevante (exceções, contratação segura, rastreabilidade, auditoria de fornecedores, KPIs de governação) \n **Quando** é criada ou revista \n **Então** é submetida a aprovação formal da direção, com versão, data e aprovador registados antes de entrar em vigor \n- **Dado** uma política em vigor \n **Quando** chega o ciclo de auditoria definido (no máximo anual) \n **Então** é auditada a aderência prática, registam-se desvios e gera-se ação corretiva com owner e prazo \n\n**Checklist.** \n- [ ] Inventário das políticas organizacionais relevantes do capítulo mantido e versionado, com estado (Obrigatória/Recomendado), owner e data da última aprovação \n- [ ] Cada política tem aprovação formal da direção registada (versão, data, aprovador) antes de entrar em vigor; revisão pelo menos anual ou após mudança organizacional significativa \n- [ ] Auditoria periódica de aderência executada por ciclo definido, com desvios registados e ações corretivas (owner + prazo) acompanhadas até fecho \n\n:::\n\n**Artefactos & evidências.** Inventário versionado de políticas com estado e owner; registo de aprovação formal pela direção (versão/data/aprovador); relatório de auditoria de aderência por ciclo; plano de ações corretivas para desvios. \n\n**Proporcionalidade L1–L3.** \n| L1 | L2 | L3 |\n|----|----|----|\n| Políticas obrigatórias aprovadas; auditoria informal anual | Conjunto completo aprovado; auditoria formal anual com registo de desvios | Conjunto completo aprovado; auditoria formal ≤ anual + revisão por mudança organizacional; ações corretivas rastreadas até fecho |\n\n**Integração no SDLC.** \n| Fase | Trigger | Responsável | SLA |\n|------|---------|-------------|-----|\n| Planeamento | Criação ou revisão de política | GRC / Compliance + CISO + Gestão Executiva (aprovação) | Aprovação antes da entrada em vigor |\n| Auditoria | Ciclo periódico (≤ anual) ou mudança organizacional | GRC / Compliance + AppSec Engineer | Auditoria concluída no ciclo; ações corretivas com prazo definido |\n\n**Ligações úteis.** \n- [Checklist de Revisão Periódica — Governança e Contratação](/sbd-toe/sbd-manual/governanca-contratacao/canon/checklist-revisao)\n- [Modelo formal de governação — US-12](#us-12---formalização-de-modelo-de-governação-por-nível-de-risco)\n- [Processo Canónico de Gestão de Exceções](./addon/processo-excecoes)\n- [Política de Gestão de Exceções de Segurança](/sbd-toe/assets/policies/policy-gestao-excecoes)\n- [Política de Contratação Segura](/sbd-toe/assets/policies/policy-contratacao-segura)\n- [Política de Rastreabilidade Organizacional](/sbd-toe/assets/policies/policy-rastreabilidade-organizacional)\n- [Política de KPIs de Governação de Segurança](/sbd-toe/assets/policies/policy-kpis-governacao)\n\n---"}
|
|
3706
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--artefactos-esperados", "chunk_kind": "table_section", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "table_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--artefactos-esperados", "relation_hints": [], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "📦 Artefactos esperados"], "size_estimate": {"approx_tokens": 322, "chars": 1288}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## 📦 Artefactos esperados\n\n| Artefacto | Evidência |\n|-----------|-----------|\n| Registo de exceções com alçadas | Ferramenta GRC versionada, decisões auditáveis |\n| Contratos com cláusulas | Documentos validados juridicamente |\n| Relatórios de fornecedores | Auditorias e findings, análise técnica |\n| Dashboard organizacional | Métricas por projeto e aplicação |\n| Relatórios KPIs | Consolidação trimestral/semestral |\n| Formulário de validação de fornecedores | Questionário preenchido, Análise AppSec, GRC registo |\n| Tabela de exceções com calendário de revalidação | Rastreabilidade com datas de vencimento |\n| Repositório de conformidade por app | Ficheiro YAML/MD versionado, Histórico auditável |\n| Documento de designação de owners | Registo centralizado com formação validada |\n| Relatórios de validação periódica | Checklist + Plano de acção, histórico ciclos |\n| Dashboard de KPIs e maturidade | Métricas por capítulo, Tendências históricas |\n| Política de Governação SbD-ToE | Documento aprovado, Níveis de alçada, Template de decisão |\n| Checklist de conformidade centralizado | Ficheiro versionado por app (YAML/MD), Git history |\n| Calendário de reavaliação de fornecedores | Planeamento trimestral/semestral/anual, Notificações automáticas |\n\n---", "title": "📦 Artefactos esperados", "traceability": {"line_end": 1024, "line_start": 1004, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--artefactos-esperados"}, "vector_text": "📦 Artefactos esperados\n\n## 📦 Artefactos esperados\n\n| Artefacto | Evidência |\n|-----------|-----------|\n| Registo de exceções com alçadas | Ferramenta GRC versionada, decisões auditáveis |\n| Contratos com cláusulas | Documentos validados juridicamente |\n| Relatórios de fornecedores | Auditorias e findings, análise técnica |\n| Dashboard organizacional | Métricas por projeto e aplicação |\n| Relatórios KPIs | Consolidação trimestral/semestral |\n| Formulário de validação de fornecedores | Questionário preenchido, Análise AppSec, GRC registo |\n| Tabela de exceções com calendário de revalidação | Rastreabilidade com datas de vencimento |\n| Repositório de conformidade por app | Ficheiro YAML/MD versionado, Histórico auditável |\n| Documento de designação de owners | Registo centralizado com formação validada |\n| Relatórios de validação periódica | Checklist + Plano de acção, histórico ciclos |\n| Dashboard de KPIs e maturidade | Métricas por capítulo, Tendências históricas |\n| Política de Governação SbD-ToE | Documento aprovado, Níveis de alçada, Template de decisão |\n| Checklist de conformidade centralizado | Ficheiro versionado por app (YAML/MD), Git history |\n| Calendário de reavaliação de fornecedores | Planeamento trimestral/semestral/anual, Notificações automáticas |\n\n---"}
|
|
3707
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-proporcionalidade-l1l3", "chunk_kind": "table_section", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "table_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-proporcionalidade-l1l3", "relation_hints": [], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "⚖️ Matriz de proporcionalidade L1–L3"], "size_estimate": {"approx_tokens": 428, "chars": 1711}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## ⚖️ Matriz de proporcionalidade L1–L3\n\n| Prática | L1 | L2 | L3 |\n|---------|----|----|----|\n| Exceções formais com alçadas | Opcional | Recomendado | Obrigatório |\n| Cláusulas contratuais | Recomendado | Obrigatório | Obrigatório + auditorias |\n| Validação de fornecedores (inicial) | Opcional | Recomendado | Obrigatório |\n| Rastreabilidade organizacional | Básico | Recomendado | Obrigatório |\n| KPIs de governação | Básico | Recomendado | Obrigatório |\n| Fluxo formal de validação fornecedores | Opcional | Recomendado | Obrigatório |\n| Revisão contínua de exceções | Básico | Recomendado | Obrigatório |\n| Repositório de conformidade por app | Básico | Recomendado | Obrigatório |\n| Designação formal de owners de segurança | Recomendado | Obrigatório | Obrigatório |\n| Validação periódica de conformidade | Anual | Semestral | Trimestral |\n| KPIs de maturidade e reporta executiva | Básico | Recomendado | Obrigatório |\n| Modelo formal de governação | Básico | Recomendado | Obrigatório |\n| Checklist centralizado por capítulo | Básico | Recomendado | Obrigatório |\n| Reavaliação de fornecedores pós-onboarding | Anual | Semestral | Trimestral / evento crítico |\n| **Preparação técnica de contractors** | Básico | Recomendado | Obrigatório + quiz validado |\n| **Trilho de formação pré-acesso** | Básico | Obrigatório | Obrigatório + 80% score |\n| **Offboarding seguro** | Básico | Obrigatório | Obrigatório + audit trail |\n| **Monitorização contínua de fornecedores** | Não | Recomendado | Obrigatório |\n| **Revisão trimestral de acesso (contractors)** | Semestral | Trimestral | Trimestral |\n| **Feedback pós-projeto** | Opcional | Recomendado | Obrigatório |\n\n---", "title": "⚖️ Matriz de proporcionalidade L1–L3", "traceability": {"line_end": 1051, "line_start": 1025, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--matriz-de-proporcionalidade-l1l3"}, "vector_text": "⚖️ Matriz de proporcionalidade L1–L3\n\n## ⚖️ Matriz de proporcionalidade L1–L3\n\n| Prática | L1 | L2 | L3 |\n|---------|----|----|----|\n| Exceções formais com alçadas | Opcional | Recomendado | Obrigatório |\n| Cláusulas contratuais | Recomendado | Obrigatório | Obrigatório + auditorias |\n| Validação de fornecedores (inicial) | Opcional | Recomendado | Obrigatório |\n| Rastreabilidade organizacional | Básico | Recomendado | Obrigatório |\n| KPIs de governação | Básico | Recomendado | Obrigatório |\n| Fluxo formal de validação fornecedores | Opcional | Recomendado | Obrigatório |\n| Revisão contínua de exceções | Básico | Recomendado | Obrigatório |\n| Repositório de conformidade por app | Básico | Recomendado | Obrigatório |\n| Designação formal de owners de segurança | Recomendado | Obrigatório | Obrigatório |\n| Validação periódica de conformidade | Anual | Semestral | Trimestral |\n| KPIs de maturidade e reporta executiva | Básico | Recomendado | Obrigatório |\n| Modelo formal de governação | Básico | Recomendado | Obrigatório |\n| Checklist centralizado por capítulo | Básico | Recomendado | Obrigatório |\n| Reavaliação de fornecedores pós-onboarding | Anual | Semestral | Trimestral / evento crítico |\n| **Preparação técnica de contractors** | Básico | Recomendado | Obrigatório + quiz validado |\n| **Trilho de formação pré-acesso** | Básico | Obrigatório | Obrigatório + 80% score |\n| **Offboarding seguro** | Básico | Obrigatório | Obrigatório + audit trail |\n| **Monitorização contínua de fornecedores** | Não | Recomendado | Obrigatório |\n| **Revisão trimestral de acesso (contractors)** | Semestral | Trimestral | Trimestral |\n| **Feedback pós-projeto** | Opcional | Recomendado | Obrigatório |\n\n---"}
|
|
3708
|
+
{"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--recomendacoes-finais", "chunk_kind": "checklist_section", "document_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle", "document_role": "aplicacao_lifecycle", "filter_tags": {"authority_class": "normative", "bundle_id": "14-governanca-contratacao", "chunk_kind": "checklist_section", "document_role": "aplicacao_lifecycle", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {"UserStory": ["US-01", "US-02", "US-04", "US-05", "US-06", "US-07", "US-08", "US-09", "US-10", "US-11", "US-12", "US-13", "US-14", "US-15", "US-16", "US-17", "US-18", "US-19", "US-20"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--recomendacoes-finais", "relation_hints": [], "section_path": ["Aplicação de Governança & Contratação no Ciclo de Vida", "🏁 Recomendações finais"], "size_estimate": {"approx_tokens": 546, "chars": 2183}, "source_mode": "explicit", "support_profiles": ["consult", "guide"], "text": "## 🏁 Recomendações finais\n\n- **Exceções sem registo = risco invisível.** Operacionalize US-01 (com alçadas claras) e US-07 para garantir rastreabilidade contínua e revalidação automática. \n- **Modelo formal é o alicerce.** US-12 documenta governação com critérios explícitos, alçadas por L1–L3, e formação obrigatória para approvers (Cap. 13). \n- **Fornecedores devem ser parte do modelo SbD-ToE.** Use US-02, US-06, US-14, e US-18 para integração contratual, validação inicial, reavaliação periódica, e monitorização contínua. \n- **Contractors merecem ciclo de vida dedicado.** US-15 (preparação técnica), US-16 (formação obrigatória), US-17 (offboarding) e US-19 (revisão de acesso) garantem que contractors são preparados, mantêm least privilege, e saem seguramente. \n- **Designação clara de owners elimina responsabilidade dispersa.** US-09 garante continuidade de decisões de segurança com formação validada. \n- **Repositório centralizado de conformidade dá visibilidade total.** US-08 e US-13 consolidam estado de todas as práticas por aplicação, capítulo e ciclo. \n- **Validações periódicas detetam desvios cedo.** US-10 integra revisão contínua no ciclo de vida; US-13 valida por capítulo; US-14 reavalia fornecedores; US-19 valida acesso de contractors. \n- **KPIs de governação são a medida objetiva da maturidade.** US-05 e US-11 permitem decisão estratégica baseada em evidência (% conformidade, % exceções resolvidas, % fornecedores auditados). \n- **Rastreabilidade organizacional dá transparência à gestão.** US-04 agregada com US-08, US-10, US-13, US-14, US-20 cria visibilidade de risco em todos os níveis. \n- **Preparação e feedback contínuos melhoram qualidade de contractors.** US-15, US-16, US-20 criam ciclo de melhoria contínua e base de dados de avaliação para re-hire. \n- **Este capítulo é o \"cimento\" que une os restantes 2–13:** torna práticas visíveis, auditáveis, rastreáveis e sustentáveis ao longo do tempo. Sem governação formal (US-12), controlo sistemático (US-13), ciclo de vida de contractors (US-15–17, 19–20), e reavaliação contínua (US-01, US-07, US-14, US-18), o SbD-ToE fica limitado à prática técnica pontual.", "title": "🏁 Recomendações finais", "traceability": {"line_end": 1064, "line_start": 1052, "source_path": "010-sbd-manual/14-governanca-contratacao/aplicacao-lifecycle.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-aplicacao-lifecycle--aplicacao-de-governanca-contratacao-no-ciclo-de-vida--recomendacoes-finais"}, "vector_text": "🏁 Recomendações finais\n\n## 🏁 Recomendações finais\n\n- **Exceções sem registo = risco invisível.** Operacionalize US-01 (com alçadas claras) e US-07 para garantir rastreabilidade contínua e revalidação automática. \n- **Modelo formal é o alicerce.** US-12 documenta governação com critérios explícitos, alçadas por L1–L3, e formação obrigatória para approvers (Cap. 13). \n- **Fornecedores devem ser parte do modelo SbD-ToE.** Use US-02, US-06, US-14, e US-18 para integração contratual, validação inicial, reavaliação periódica, e monitorização contínua. \n- **Contractors merecem ciclo de vida dedicado.** US-15 (preparação técnica), US-16 (formação obrigatória), US-17 (offboarding) e US-19 (revisão de acesso) garantem que contractors são preparados, mantêm least privilege, e saem seguramente. \n- **Designação clara de owners elimina responsabilidade dispersa.** US-09 garante continuidade de decisões de segurança com formação validada. \n- **Repositório centralizado de conformidade dá visibilidade total.** US-08 e US-13 consolidam estado de todas as práticas por aplicação, capítulo e ciclo. \n- **Validações periódicas detetam desvios cedo.** US-10 integra revisão contínua no ciclo de vida; US-13 valida por capítulo; US-14 reavalia fornecedores; US-19 valida acesso de contractors. \n- **KPIs de governação são a medida objetiva da maturidade.** US-05 e US-11 permitem decisão estratégica baseada em evidência (% conformidade, % exceções resolvidas, % fornecedores auditados). \n- **Rastreabilidade organizacional dá transparência à gestão.** US-04 agregada com US-08, US-10, US-13, US-14, US-20 cria visibilidade de risco em todos os níveis. \n- **Preparação e feedback contínuos melhoram qualidade de contractors.** US-15, US-16, US-20 criam ciclo de melhoria contínua e base de dados de avaliação para re-hire. \n- **Este capítulo é o \"cimento\" que une os restantes 2–13:** torna práticas visíveis, auditáveis, rastreáveis e sustentáveis ao longo do tempo. Sem governação formal (US-12), controlo sistemático (US-13), ciclo de vida de contractors (US-15–17, 19–20), e reavaliação contínua (US-01, US-07, US-14, US-18), o SbD-ToE fica limitado à prática técnica pontual."}
|
|
3709
3709
|
{"authority_class": "historical", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-canon-20-checklist-revisao--checklist-de-revisao-periodica-governanca-e-contratacao", "chunk_kind": "narrative_section", "document_id": "010-sbd-manual-14-governanca-contratacao-canon-20-checklist-revisao", "document_role": "legacy_canon", "filter_tags": {"authority_class": "historical", "bundle_id": "14-governanca-contratacao", "chunk_kind": "narrative_section", "document_role": "legacy_canon", "domain": ["governance-and-procurement"], "phase": ["govern"], "risk_level": ["L1", "L2", "L3"]}, "mentioned_entities": {"Requirement": ["GOV-001", "GOV-012"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-canon-20-checklist-revisao--checklist-de-revisao-periodica-governanca-e-contratacao", "relation_hints": [], "section_path": ["Checklist de Revisão Periódica - Governança e Contratação"], "size_estimate": {"approx_tokens": 114, "chars": 453}, "source_mode": "explicit", "support_profiles": ["implementation"], "text": "# Checklist de Revisão Periódica - Governança e Contratação\n\nEste checklist aplica-se a **projetos, aplicações ou contratos** com impacto técnico e visa validar a aplicação prática das práticas prescritas no Capítulo 14 - Governança e Contratação (`GOV-001` a `GOV-012`).\n\n> 📌 Deve ser usado em revisões formais, auditorias internas, milestones de projeto ou ciclos de revalidação técnica.\n\n---", "title": "Checklist de Revisão Periódica - Governança e Contratação", "traceability": {"line_end": 18, "line_start": 11, "source_path": "010-sbd-manual/14-governanca-contratacao/canon/20-checklist-revisao.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-canon-20-checklist-revisao--checklist-de-revisao-periodica-governanca-e-contratacao"}, "vector_text": "Checklist de Revisão Periódica - Governança e Contratação\n\n# Checklist de Revisão Periódica - Governança e Contratação\n\nEste checklist aplica-se a **projetos, aplicações ou contratos** com impacto técnico e visa validar a aplicação prática das práticas prescritas no Capítulo 14 - Governança e Contratação (`GOV-001` a `GOV-012`).\n\n> 📌 Deve ser usado em revisões formais, auditorias internas, milestones de projeto ou ciclos de revalidação técnica.\n\n---"}
|
|
3710
3710
|
{"authority_class": "historical", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-canon-20-checklist-revisao--checklist-de-revisao-periodica-governanca-e-contratacao--itens-de-verificacao", "chunk_kind": "table_section", "document_id": "010-sbd-manual-14-governanca-contratacao-canon-20-checklist-revisao", "document_role": "legacy_canon", "filter_tags": {"authority_class": "historical", "bundle_id": "14-governanca-contratacao", "chunk_kind": "table_section", "document_role": "legacy_canon", "domain": ["dependencies-sbom-sca", "governance-and-procurement"], "phase": ["govern"], "risk_level": ["L1", "L2", "L3"]}, "mentioned_entities": {"Requirement": ["DEP-014", "GOV-001", "GOV-002", "GOV-003", "GOV-004", "GOV-005", "GOV-006", "GOV-007", "GOV-008", "GOV-009", "GOV-010", "GOV-011", "GOV-012", "GOV-013", "GOV-014"]}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-canon-20-checklist-revisao--checklist-de-revisao-periodica-governanca-e-contratacao--itens-de-verificacao", "relation_hints": [], "section_path": ["Checklist de Revisão Periódica - Governança e Contratação", "📋 Itens de Verificação"], "size_estimate": {"approx_tokens": 866, "chars": 3462}, "source_mode": "explicit", "support_profiles": ["implementation"], "text": "## 📋 Itens de Verificação\n\n| Item | Verificado? |\n|------------------------------------------------------------------------------------------------------------------------|-------------|\n| Existe modelo formal de governação de segurança aprovado pela direção e revisto há ≤12 meses? (`GOV-001`) | ☐ |\n| A aplicação ou projeto tem owner de segurança formalmente designado e registado? (`GOV-002`) | ☐ |\n| O nível de criticidade (L1–L3) está documentado e justificado? | ☐ |\n| As alçadas de aprovação por nível de risco estão documentadas e conhecidas pelos decisores, com escalonamento rastreável? (`GOV-003`) | ☐ |\n| Os requisitos mínimos proporcionais ao risco estão identificados e aplicados? | ☐ |\n| Existe processo formal de gestão de exceções, registando cada exceção com owner, medida compensatória, evidência referenciável, data de expiração e alerta de revalidação (máx. 90 dias)? (`GOV-004`/`GOV-005`) | ☐ |\n| Os contratos com terceiros incluem cláusulas de segurança proporcionais ao risco? (`GOV-006`) | ☐ |\n| Os fornecedores com acesso técnico foram validados (questionário/checklist; L3: SBOM, SLA de incidentes, direito de auditoria) antes de onboarding? (`GOV-007`) | ☐ |\n| Existe rastreabilidade organizacional por aplicação ligando risco → requisitos → exceções → fornecedores → owner? (`GOV-008`) | ☐ |\n| A cadeia de autoridade de cada decisão de risco (quem pediu, avaliou, aprovou) é verificável, com evidência referenciável e retida? (`GOV-009`) | ☐ |\n| Existe ciclo de revisão periódica de conformidade por tipo de ativo (L3 trimestral, L2 semestral, fornecedores anual), com ações corretivas (owner e prazo)? (`GOV-010`) | ☐ |\n| Existem KPIs de governação definidos, recolhidos e reportados à gestão, com thresholds que despoletam ação corretiva? (`GOV-011`) | ☐ |\n| Existe avaliação de maturidade ativa (SAMM/DSOMM ou equivalente) há ≤12 meses, com plano de evolução (L3)? (`GOV-012`) | ☐ |\n| A aplicação consta da matriz de controlo das práticas SbD-ToE e as políticas organizacionais relevantes estão formalmente aprovadas e auditadas? | ☐ |\n| Os contratos com provedores de modelos de IA incluem data retention, training opt-out, localização RGPD (Art. 44–49), audit rights, SLA de notificação de mudanças e conformidade AI Act (Art. 53/55 GPAI), constando o provedor da lista aprovada (`DEP-014`)? | ☐ |\n| Existe processo formal de offboarding seguro (revogação de acesso, recuperação de ativos, rotação de segredos) e os decisores têm formação SbD válida nos últimos 12 meses (Cap. 13)? | ☐ |\n| Os terceiros completam onboarding técnico e formação obrigatória (por perfil, com quiz e sandbox) com *sign-off* registado **antes** de acesso a sistemas, sendo o registo rastreável e retido conforme regulação (`GOV-013`)? | ☐ |\n| O acesso de contractors ativos é revisto periodicamente (semestral L1 / trimestral L2–L3) com validação de necessidade, remoção de acesso excessivo no próprio dia, revisão assinada e mudanças em *audit trail* (`GOV-014`)? | ☐ |\n\n---", "title": "📋 Itens de Verificação", "traceability": {"line_end": 43, "line_start": 19, "source_path": "010-sbd-manual/14-governanca-contratacao/canon/20-checklist-revisao.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-canon-20-checklist-revisao--checklist-de-revisao-periodica-governanca-e-contratacao--itens-de-verificacao"}, "vector_text": "📋 Itens de Verificação\n\n## 📋 Itens de Verificação\n\n| Item | Verificado? |\n|------------------------------------------------------------------------------------------------------------------------|-------------|\n| Existe modelo formal de governação de segurança aprovado pela direção e revisto há ≤12 meses? (`GOV-001`) | ☐ |\n| A aplicação ou projeto tem owner de segurança formalmente designado e registado? (`GOV-002`) | ☐ |\n| O nível de criticidade (L1–L3) está documentado e justificado? | ☐ |\n| As alçadas de aprovação por nível de risco estão documentadas e conhecidas pelos decisores, com escalonamento rastreável? (`GOV-003`) | ☐ |\n| Os requisitos mínimos proporcionais ao risco estão identificados e aplicados? | ☐ |\n| Existe processo formal de gestão de exceções, registando cada exceção com owner, medida compensatória, evidência referenciável, data de expiração e alerta de revalidação (máx. 90 dias)? (`GOV-004`/`GOV-005`) | ☐ |\n| Os contratos com terceiros incluem cláusulas de segurança proporcionais ao risco? (`GOV-006`) | ☐ |\n| Os fornecedores com acesso técnico foram validados (questionário/checklist; L3: SBOM, SLA de incidentes, direito de auditoria) antes de onboarding? (`GOV-007`) | ☐ |\n| Existe rastreabilidade organizacional por aplicação ligando risco → requisitos → exceções → fornecedores → owner? (`GOV-008`) | ☐ |\n| A cadeia de autoridade de cada decisão de risco (quem pediu, avaliou, aprovou) é verificável, com evidência referenciável e retida? (`GOV-009`) | ☐ |\n| Existe ciclo de revisão periódica de conformidade por tipo de ativo (L3 trimestral, L2 semestral, fornecedores anual), com ações corretivas (owner e prazo)? (`GOV-010`) | ☐ |\n| Existem KPIs de governação definidos, recolhidos e reportados à gestão, com thresholds que despoletam ação corretiva? (`GOV-011`) | ☐ |\n| Existe avaliação de maturidade ativa (SAMM/DSOMM ou equivalente) há ≤12 meses, com plano de evolução (L3)? (`GOV-012`) | ☐ |\n| A aplicação consta da matriz de controlo das práticas SbD-ToE e as políticas organizacionais relevantes estão formalmente aprovadas e auditadas? | ☐ |\n| Os contratos com provedores de modelos de IA incluem data retention, training opt-out, localização RGPD (Art. 44–49), audit rights, SLA de notificação de mudanças e conformidade AI Act (Art. 53/55 GPAI), constando o provedor da lista aprovada (`DEP-014`)? | ☐ |\n| Existe processo formal de offboarding seguro (revogação de acesso, recuperação de ativos, rotação de segredos) e os decisores têm formação SbD válida nos últimos 12 meses (Cap. 13)? | ☐ |\n| Os terceiros completam onboarding técnico e formação obrigatória (por perfil, com quiz e sandbox) com *sign-off* registado **antes** de acesso a sistemas, sendo o registo rastreável e retido conforme regulação (`GOV-013`)? | ☐ |\n| O acesso de contractors ativos é revisto periodicamente (semestral L1 / trimestral L2–L3) com validação de necessidade, remoção de acesso excessivo no próprio dia, revisão assinada e mudanças em *audit trail* (`GOV-014`)? | ☐ |\n\n---"}
|
|
3711
3711
|
{"authority_class": "historical", "bundle_id": "14-governanca-contratacao", "chunk_id": "010-sbd-manual-14-governanca-contratacao-canon-20-checklist-revisao--checklist-de-revisao-periodica-governanca-e-contratacao--integracao-operacional", "chunk_kind": "narrative_section", "document_id": "010-sbd-manual-14-governanca-contratacao-canon-20-checklist-revisao", "document_role": "legacy_canon", "filter_tags": {"authority_class": "historical", "bundle_id": "14-governanca-contratacao", "chunk_kind": "narrative_section", "document_role": "legacy_canon", "domain": [], "phase": ["govern"], "risk_level": []}, "mentioned_entities": {}, "record_id": "mcp::010-sbd-manual-14-governanca-contratacao-canon-20-checklist-revisao--checklist-de-revisao-periodica-governanca-e-contratacao--integracao-operacional", "relation_hints": [], "section_path": ["Checklist de Revisão Periódica - Governança e Contratação", "🔄 Integração Operacional"], "size_estimate": {"approx_tokens": 79, "chars": 316}, "source_mode": "explicit", "support_profiles": ["implementation"], "text": "## 🔄 Integração Operacional\n\n- Pode ser usado como **template de revisão recorrente** em Jira, Confluence, SharePoint ou Forms;\n- Deve ter validação conjunta por **AppSec, GRC e gestão de produto**;\n- Cada item exige **evidência rastreável e versionada**, conforme práticas do Cap. 14.\n\n---", "title": "🔄 Integração Operacional", "traceability": {"line_end": 51, "line_start": 44, "source_path": "010-sbd-manual/14-governanca-contratacao/canon/20-checklist-revisao.md", "unit_id": "010-sbd-manual-14-governanca-contratacao-canon-20-checklist-revisao--checklist-de-revisao-periodica-governanca-e-contratacao--integracao-operacional"}, "vector_text": "🔄 Integração Operacional\n\n## 🔄 Integração Operacional\n\n- Pode ser usado como **template de revisão recorrente** em Jira, Confluence, SharePoint ou Forms;\n- Deve ter validação conjunta por **AppSec, GRC e gestão de produto**;\n- Cada item exige **evidência rastreável e versionada**, conforme práticas do Cap. 14.\n\n---"}
|