Hari 28: Compliance as Code, 3 Test InSpec Pass

Compliance as Code — Bukan Checklist Manual

Selama challenge ini kita pakai scanner: Gitleaks (secret), Trivy (SCA), Semgrep (SAST), Checkov (IaC), ZAP (DAST). Scanner menjawab pertanyaan "apa ada vulnerability?". Tapi ada pertanyaan lain yang scanner nggak jawab: "apakah infrastruktur memenuhi compliance requirements?"

Untuk itu ada Compliance as Code — test keamanan infrastruktur yang bisa di-run berulang, version-controlled, dan di-integrate ke CI. Tool yang dipakai: Chef InSpec.

Apa itu Chef InSpec?

InSpec adalah framework dari Chef (sekarang Progress) untuk menulis compliance test dengan bahasa Ruby. Test-nya disebut "controls" — setiap control punya impact level, title, description, dan matcher (seperti RSpec).

Contoh control:

control 'ssh-port-closed' do
  impact 1.0
  title 'SSH port should be closed'
  desc 'Port 22 should not be open to public internet.'

  describe port(22) do
    it { should_not be_listening }
  end
end

InSpec menjalankan matcher (port(22) should_not be_listening) terhadap target (local machine, SSH remote, atau Docker container) dan report PASS/FAIL per control.

Setup — Install + Profile + Run

Step 1: Install InSpec

brew install --cask chef/chef/inspec
inspec --version
# 5.22.3

Step 2: Buat Profile

security/inspec-profiles/securebank/
├── inspec.yml          # Profile metadata
└── controls/
    ├── network.rb     # SSH + API port checks
    └── process.rb    # Non-root process check

Step 3: Run

# Start Go binary
go build -o securebank ./cmd/api
JWT_SECRET=test PORT=8080 ./securebank &

# Run InSpec
inspec exec security/inspec-profiles/securebank/ --chef-license accept

3 Controls — Apa yang Di-Test?

Control 1: SSH Port Closed (Impact 1.0)

describe port(22) do
  it { should_not be_listening }
end

Port 22 (SSH) tidak boleh listening. Di local dev machine, ini valid — nggak ada SSH server yang jalan. Di production, ini bisa di-test terhadap server yang seharusnya hanya pakai SSH bastion atau nggak pakai SSH sama sekali (SSM Session Manager).

Impact 1.0 (critical) karena SSH open ke internet = salah satu vektor attack paling umum (brute force, credential stuffing).

Control 2: API Port Listening (Impact 0.7)

describe port(8080) do
  it { should be_listening }
end

SecureBank API harus listening di port 8080. Kalau nggak, aplikasi down. Impact 0.7 (high) karena ini availability issue, bukan security issue langsung — tapi kalau API nggak jalan, security control lain juga nggak berfungsi.

Control 3: No Root Process (Impact 1.0)

describe processes('securebank') do
  its('users') { should_not include 'root' }
end

SecureBank binary tidak boleh jalan sebagai root. Root process punya akses penuh ke filesystem, network, dan kernel — kalau ada exploit, attacker dapat root access.

Impact 1.0 (critical) karena privilege escalation: process yang jalan sebagai root = attack surface yang jauh lebih besar.

Hasil: 3/3 Pass

Profile:   SecureBank API Compliance Profile (securebank-compliance)
Version:   0.1.0
Target:    local://

  ✔  ssh-port-closed: SSH port should be closed
     ✔  Port 22 is expected not to be listening
  ✔  api-port-listening: API port should be listening
     ✔  Port 8080 is expected to be listening
  ✔  no-root-process: Application should not run as root
     ✔  Processes securebank users is expected not to include "root"

Profile Summary: 3 successful controls, 0 control failures, 0 controls skipped
Test Summary: 3 successful, 0 failures, 0 skipped

Semua pass. SSH port tertutup, API listening di 8080, dan process securebank jalan sebagai user biasa (bukan root).

Pelajaran yang Didapat

1. Compliance as Code = testable security assertions. Daripada checklist manual "apakah SSH port tertutup?", InSpec bikin assertions yang bisa di-run berulang dan di-integrate ke CI. Kalau control fail, langsung ketahuan sebelum merge.

2. InSpec matchers adalah RSpec-based. port(), processes(), file(), command() — semua matcher InSpec pakai RSpec syntax (it { should be_listening }). Familiar untuk yang pernah pakai Ruby testing. Nggak perlu belajar syntax baru kalau pernah RSpec.

3. Impact level menentukan prioritas. 1.0 = critical (SSH open, root process), 0.7 = high (API availability). InSpec report mengikuti impact untuk prioritas. Kalau control impact 1.0 fail, harus fix segera. Kalau 0.7, penting tapi bukan emergency.

4. InSpec bisa test local, remote, dan Docker. inspec exec profile/ -t local:// untuk local machine. -t ssh://user@host untuk remote server. -t docker://container_id untuk Docker container. Same profile, different targets — fleksibel untuk dev, staging, dan production.

5. gem install inspec vs brew install --cask. InSpec 7.x gem hanya ship library untuk Ruby, bukan CLI executable. Untuk CLI, butuh Chef Workstation installer (.pkg). Homebrew cask handle ini — tapi butuh sudo password. Nggak bisa install di background.

Kesimpulan

Day 28 selesai. Compliance as Code dengan Chef InSpec. 3 controls: SSH closed, API listening, non-root process. Semua pass. InSpec profile sekarang version-controlled di repo — bisa di-run berulang dan di-integrate ke CI di Day 29 (Pipeline Consolidation).

Key insight: scanner dan compliance test saling melengkapi. Scanner menjawab "ada vulnerability?", compliance test menjawab "apakah memenuhi policy?". Keduanya penting untuk DevSecOps yang mature.

Besok Day 29: Pipeline Consolidation — gabungkan semua scanner + InSpec ke satu unified security pipeline. Sampai jumpa besok!

---

Repo: https://github.com/stayrelevantid/chalange-devsecops