# Kanit: Complete Technical Specification & Documentation

Kanit is an open-source, local-first continuous compliance CLI and automated evidence collection engine for AWS and GitHub. It replaces expensive closed-source SaaS platforms (such as Vanta, Drata, and Secureframe) by providing an auditor-grade, developer-friendly compliance pipeline that runs locally or inside CI/CD.

Website: https://getkanit.com
Repository: https://github.com/aliefe04/kanit
License: MIT License
Contact: info@getkanit.com

---

## 1. Executive Summary & Architecture

### Core Value Proposition
Compliance management platforms charge startups $15,000 to $30,000+ annually while requiring broad read/write access to production cloud environments and storing sensitive infrastructure topologies in third-party clouds.

Kanit disrupts this model:
- **Local-First Architecture**: Evaluates AWS and GitHub APIs directly from the developer workstation or CI/CD runner. Zero data, credentials, or architectural schematics are transmitted to third-party servers.
- **Cryptographic Evidence Sealing**: Collects raw configuration states and generates a canonical SHA-256 hash manifest. Auditors can independently verify that evidence has not been tampered with since collection.
- **Developer-Native Remediation**: Instead of generating non-actionable dashboard alerts, Kanit outputs copy-paste Terraform (HCL) blocks and CLI commands to fix non-compliant controls.
- **Continuous CI/CD Gate**: Enforces compliance guardrails on every pull request, failing builds that violate critical security controls.

---

## 2. 17 Automated Controls Matrix

Kanit implements 17 automated control rules written in TypeScript. Each rule evaluates live or mocked API responses against security benchmarks.

### AWS Controls (10 Automated Checks)

1. **AWS-01: Root Account MFA Enforced**
   - Severity: CRITICAL
   - Framework Mapping: SOC 2 (CC6.1, CC6.2) | ISO 27001 (A.5.15, A.8.5) | CIS AWS (1.5)
   - Description: Verifies that Multi-Factor Authentication (MFA) is enabled for the AWS root account.
   - Remediation: Enable virtual MFA or hardware security key via AWS IAM Console.

2. **AWS-02: Zero Active Root Access Keys**
   - Severity: CRITICAL
   - Framework Mapping: SOC 2 (CC6.1, CC6.3) | ISO 27001 (A.5.15, A.8.5) | CIS AWS (1.4)
   - Description: Confirms that no active API access keys exist for the root user.
   - Remediation: Delete root access keys via AWS IAM Console.

3. **AWS-03: S3 Block Public Access Enforced**
   - Severity: CRITICAL
   - Framework Mapping: SOC 2 (CC6.1, CC6.6) | ISO 27001 (A.5.15, A.8.12) | CIS AWS (2.1.5)
   - Description: Validates that account-level or bucket-level S3 Block Public Access settings are enabled.
   - Remediation: Apply `aws_s3_bucket_public_access_block` Terraform resource or `aws s3api put-public-access-block`.

4. **AWS-04: Multi-Region CloudTrail Logging Active**
   - Severity: HIGH
   - Framework Mapping: SOC 2 (CC7.2, CC7.3) | ISO 27001 (A.8.15, A.8.17) | CIS AWS (3.1)
   - Description: Confirms that an active multi-region CloudTrail is configured and recording management events with log validation enabled.
   - Remediation: Create multi-region trail with `aws_cloudtrail` Terraform resource.

5. **AWS-05: Default EBS Volume Encryption Enabled**
   - Severity: HIGH
   - Framework Mapping: SOC 2 (CC6.1, CC6.7) | ISO 27001 (A.8.24) | CIS AWS (2.2.1)
   - Description: Verifies that account-level default encryption is enabled for new Amazon EBS volumes.
   - Remediation: Run `aws ec2 enable-ebs-encryption-by-default` or configure `aws_ebs_encryption_by_default`.

6. **AWS-06: RDS Instances KMS Encrypted at Rest**
   - Severity: HIGH
   - Framework Mapping: SOC 2 (CC6.1, CC6.7) | ISO 27001 (A.8.24) | CIS AWS (2.3.1)
   - Description: Verifies that all relational database instances have storage encryption enabled with AWS KMS.
   - Remediation: Set `storage_encrypted = true` and specify `kms_key_id` in `aws_db_instance`.

7. **AWS-07: IAM Strict Password Policy Enforced**
   - Severity: MEDIUM
   - Framework Mapping: SOC 2 (CC6.1) | ISO 27001 (A.5.17, A.8.5) | CIS AWS (1.8-1.11)
   - Description: Validates minimum password length (≥14 chars), uppercase, lowercase, numbers, and symbols.
   - Remediation: Update IAM account password policy via `aws iam update-account-password-policy`.

8. **AWS-08: Security Groups Ingress Restricted**
   - Severity: HIGH
   - Framework Mapping: SOC 2 (CC6.6) | ISO 27001 (A.8.20, A.8.22) | CIS AWS (5.1-5.3)
   - Description: Disallows unrestricted inbound rules (`0.0.0.0/0`) on sensitive administrative ports (22 SSH, 3389 RDP).
   - Remediation: Restrict ingress CIDR blocks in security group rules.

9. **AWS-09: IAM Access Keys Rotated Within 90 Days**
   - Severity: MEDIUM
   - Framework Mapping: SOC 2 (CC6.1) | ISO 27001 (A.5.17, A.8.5) | CIS AWS (1.14)
   - Description: Flags active IAM access keys that have not been rotated within the past 90 days.
   - Remediation: Create replacement access key, update applications, and deactivate stale key.

10. **AWS-10: S3 Bucket Server-Side Encryption (SSE)**
    - Severity: HIGH
    - Framework Mapping: SOC 2 (CC6.1, CC6.7) | ISO 27001 (A.8.24) | CIS AWS (2.1.1)
    - Description: Ensures every S3 bucket enforces default server-side encryption with SSE-S3 or SSE-KMS.
    - Remediation: Configure `aws_s3_bucket_server_side_encryption_configuration`.

### GitHub Controls (7 Automated Checks)

1. **GH-01: Organization 2FA Requirement Active**
   - Severity: CRITICAL
   - Framework Mapping: SOC 2 (CC6.1, CC6.2) | ISO 27001 (A.5.15, A.8.5)
   - Description: Validates that two-factor authentication is strictly enforced for all organization members.
   - Remediation: Enforce 2FA in GitHub Organization Security Settings.

2. **GH-02: Default Branch Protection Rules Enforced**
   - Severity: HIGH
   - Framework Mapping: SOC 2 (CC6.8, CC8.1) | ISO 27001 (A.8.28, A.8.32)
   - Description: Validates branch protection rules on `main` / `master` across all production repositories.
   - Remediation: Enable branch protection with required pull request reviews.

3. **GH-03: Mandatory Code Review (≥1 Approver)**
   - Severity: HIGH
   - Framework Mapping: SOC 2 (CC6.8, CC8.1) | ISO 27001 (A.8.28, A.8.32)
   - Description: Enforces at least 1 peer code review approval before pull requests can be merged.
   - Remediation: Set `required_approving_review_count = 1` in branch protection.

4. **GH-04: Force Pushes & Branch Deletions Prohibited**
   - Severity: HIGH
   - Framework Mapping: SOC 2 (CC6.8, CC8.1) | ISO 27001 (A.8.28, A.8.32)
   - Description: Ensures default branches cannot be force-pushed or accidentally deleted.
   - Remediation: Block force pushes and branch deletions in branch protection rules.

5. **GH-05: Signed Commits Enforced**
   - Severity: MEDIUM
   - Framework Mapping: SOC 2 (CC6.8, CC8.1) | ISO 27001 (A.8.28)
   - Description: Requires all commits to protected branches to carry verified GPG, SSH, or S/MIME signatures.
   - Remediation: Turn on "Require signed commits" in GitHub branch protection.

6. **GH-06: Dependabot Alerts & Secret Scanning Enabled**
   - Severity: HIGH
   - Framework Mapping: SOC 2 (CC7.1, CC8.1) | ISO 27001 (A.8.8, A.8.28)
   - Description: Validates that automated vulnerability alerts and push secret scanning are active.
   - Remediation: Enable Dependabot and Secret Scanning in repository Security & Analysis.

7. **GH-07: Dismiss Stale PR Approvals on New Push**
   - Severity: MEDIUM
   - Framework Mapping: SOC 2 (CC6.8, CC8.1) | ISO 27001 (A.8.28, A.8.32)
   - Description: Automatically revokes PR review approvals when new commits are pushed to the branch.
   - Remediation: Enable `dismiss_stale_reviews` in branch protection rules.

---

## 3. CLI Command Reference

### Scan Command
```bash
# Offline mock scan (no cloud credentials required)
npx @aliefe04/kanit scan --mock

# Live scan using local AWS & GitHub credentials
kanit scan --framework soc2,iso27001 --export evidence.json

# CI/CD mode with non-zero exit code on CRITICAL or HIGH failure
kanit scan --ci --fail-on high --export ./audit-output/evidence.json
```

### Remediation Command
```bash
# Generate Terraform remediation snippet for a control
kanit fix AWS-03 --mode terraform

# Generate CLI remediation command
kanit fix GH-02 --mode cli
```

### Verification Command
```bash
# Verify integrity of a sealed evidence manifest
kanit verify-evidence ./evidence.json
```

---

## 4. Competitive Comparison (Kanit vs Vanta vs Drata)

| Feature | Kanit (Open Source) | Vanta / Drata (SaaS) | Manual / Spreadsheets |
|---|---|---|---|
| **Annual License Cost** | **$0 (100% Free & Open Source)** | $15,000 – $40,000+ / year | "Free" but 300+ engineering hours |
| **Data Privacy & Architecture** | **100% Local-First (zero data leaves your environment)** | Hosted cloud SaaS; agents upload data to third party | Stored in spreadsheets & Google Drive |
| **Evidence Tamper-Resistance** | **SHA-256 Cryptographic Hash Signatures** | Platform database timestamps | Screenshots (easily modified or forged) |
| **Remediation Method** | **Automated Terraform HCL & CLI code generation** | Jira task creation & manual dashboard alerts | Manual ticket triage |
| **CI/CD Pipeline Integration** | **Native GitHub Action & CLI exit code gate** | Limited or external webhook | None |
| **Time to First Audit Proof** | **< 60 seconds (`npx @aliefe04/kanit scan --mock`)** | 2 to 6 weeks of sales & onboarding calls | 3 to 6 months of manual evidence gathering |

---

## 5. Frequently Asked Questions (FAQ)

### Can Kanit replace Vanta or Drata for startups?
Yes. For startups preparing for SOC 2 Type II or ISO 27001:2022 audits, Kanit automates the most time-consuming and expensive component: continuous evidence collection and technical control verification for cloud infrastructure (AWS) and code repositories (GitHub).

### How does Kanit's SHA-256 evidence sealing work with compliance auditors?
When Kanit executes a scan, it snapshots the raw configuration payloads from AWS and GitHub APIs, structures them into a canonical format, and computes a SHA-256 digest. This manifest is packaged into an evidence archive (`evidence.json`). Auditors can run `kanit verify-evidence` to mathematically prove that evidence has not been altered or fabricated after the scan timestamp.

### Does Kanit upload credentials or cloud topology to external servers?
No. Kanit is 100% local-first. It runs on your workstation or inside your private CI/CD runners using your standard local AWS credentials (`~/.aws/credentials` or IAM Role) and GitHub Personal Access Tokens. Zero telemetry, credentials, or architectural data are transmitted to Kanit or any third-party infrastructure.

### Does Kanit support air-gapped or offline development environments?
Yes. With the `--mock` flag, Kanit runs completely offline without any network calls, allowing teams to test compliance gates in local sandboxes and pre-commit hooks.