This record describes the current Argus product-security baseline and the measurable work Kotav Labs intends to complete against the seven CISA Secure by Design Pledge goals.
Publication status
Roadmap published
Baseline date: 14 September 2026. Reviewed at least quarterly and after material product changes.
// defined boundary
A public baseline, not a certification claim.
The scope is the customer-facing Argus SaaS service and its administration surfaces. CISA does not verify adherence to the pledge and does not endorse Kotav Labs or Argus.
Goal 1 · Operating baseline
Multi-factor authentication
Current evidence. Argus supports TOTP MFA, one-time recovery codes and protected MFA secrets. Privileged human roles are subject to MFA enforcement and step-up checks for sensitive actions.
Next measurable step. Increase default enrolment for customer accounts and publish aggregate adoption by role without exposing tenant or user information.
Goal 2 · Operating baseline
Default passwords
Current evidence. The hosted service does not ship a shared or universal default password. Customer accounts are individually created or invited and must establish an individual secret; temporary onboarding credentials must be replaced.
Next measurable step. Keep automated release checks covering onboarding, forced password change and credential-reset paths.
Goal 3 · Measured programme
Reducing vulnerability classes
Current evidence. Secure-development checks cover injection, cross-site scripting, broken access control, tenant isolation, secret exposure and vulnerable dependencies. AppSec review combines deterministic checks with contextual review of code changes.
Next measurable step. Publish class-level trend data after a stable reporting period, starting with injection, cross-site scripting and authorization defects.
Goal 4 · Provider-managed
Security patches
Current evidence. Argus is delivered as a hosted service. Kotav Labs deploys service and dependency updates centrally, so customers do not need to install product patches themselves.
Next measurable step. Measure and publish remediation time for high and critical product vulnerabilities while keeping customer-specific details confidential.
Goal 5 · Published
Vulnerability disclosure policy
Current evidence. A public policy now defines authorized good-faith research, safe harbour, excluded testing, a reporting channel and a coordinated disclosure process. A machine-readable security.txt record points to it.
Next measurable step. Review the policy annually and publish non-sensitive lessons or aggregate handling metrics when sufficient reports exist.
Goal 6 · Policy established
CVE transparency
Current evidence. Kotav Labs will seek timely CVE publication for confirmed high or critical product vulnerabilities that require customer action or show active exploitation, with CWE and CPE data where applicable.
Next measurable step. Document each applicability decision. A zero-CVE period will not be presented as proof that the product is vulnerability-free.
Goal 7 · Operating baseline
Evidence of intrusions
Current evidence. Customer-visible activity records and attributable administrative audit events cover material security and engagement actions. Security evidence is included in the service rather than sold as a separate logging add-on.
Next measurable step. Expand customer export coverage, document the baseline retention period and publish a coverage measure for identity, configuration and sensitive administrative events.
Researcher-facing policy
The disclosure policy defines authorization, safe harbour, reporting expectations and coordinated publication.