CogitaveLearn

The security baseline

The baseline is the set of controls every Cogitave product is built on. The Security Standard owns them; this unit teaches you to recognize each one and where it lives.

Secure-by-design and secure-by-default

Two principles are required of every product and service, mapped to the CISA Secure-by-Design pledge in the Secure Development Lifecycle Standard:

  • Secure-by-design. Threat modeling happens at the architecture phase, not after code exists. Design for least privilege, defense-in-depth, and zero trust - every boundary authenticates and authorizes - and fail secure (deny on error). No backdoors, no hardcoded credentials.
  • Secure-by-default. The out-of-box configuration is the safe one: deny-by-default network posture, encryption in transit and at rest on, debug and verbose-error surfaces off, audit logging on. A user must take a deliberate, recorded action to become less safe, never to become safe.

Identity and access management

IAM is scoped to three kinds of principal, each least-privilege:

  • Human. SSO/SAML with SCIM provisioning and deprovisioning, RBAC, and prompt deprovisioning.
  • Workload. No static keys - OIDC (for example GitHub Actions to cloud), moving later to SPIFFE/SVID workload identity.
  • Agent. Agent identity and authority are first-class: an agent acts under its own identity and an explicit capability and sandbox grant, never an ambient or borrowed one.

Secrets, PKI, and threat modeling

Secret management is centralized - no secrets in repos or folders - and key lifecycle (SSH commit-signing keys, release-signing keys, rotation policy) produces non-repudiation evidence. Threat modeling is a named control done per feature or system, STRIDE-style, with a dedicated threat model for the Yuva agent OS. Vulnerability management runs Dependabot, secret scanning, and code scanning (CodeQL) with remediation SLAs, and an incident-response plan covers roles, severity, and postmortem.

The controls are enforced in-repo

The baseline is not advisory. It is enforced by controls that live in the repository itself: CODEOWNERS for separation of duties, a branch ruleset, gitleaks, signed commits, secret push protection, a least-privilege GITHUB_TOKEN, and an allowed-actions allowlist.

NOTE

The Security Standard owns these controls; it does not own the process that applies them stage by stage. That is the next unit - the secure development lifecycle - which references these controls rather than restating them.