Use clear, descriptive names for custom attestation types to indicate what kind of evidence they represent. Naming convention relates toDocumentation Index
Fetch the complete documentation index at: https://docs.kosli.com/llms.txt
Use this file to discover all available pages before exploring further.
TYPE-NAME in Kosli CLI command:
control objective-evidence type-[detail]-[version]
- control objective: The high-level control or requirement the attestation supports (e.g., control id, code review, security scan, unit test)
- evidence type: The specific type of evidence being attested (e.g. tool-name, test-suite)
- detail (Optional): Additional context or detail about the attestation (e.g., type, severity-level, environment, etc.)
- version (Optional): The version of the attestation type or schema. Should follow semantic versioning (e.g., v1, v2)
detailelement may be repeated to add finer granularity if needed.- You can skip
detailandversionif not needed for your use case. - Kosli versions attestation types automatically, so
versionis often unnecessary. However, it can be useful for multiple version running at the same time, for example in shared pipelines.
- snake_case
- camelCase
- PascalCase
Examples on
TYPE-NAME:bc1-version_control-v1(BC1 version control attestation, version 1)code_review-github-pr(basic code review attestation)security_scan-snyk-high(Custom schema for Snyk scan with high severity detail)unit_test-junit-detail1-detail2-v2(Multiple detail blocks with version)