Step 0

Environment Setup

On this page

Environment Setup

Complete these steps before starting the exercises. Estimated setup time: ~10 minutes.

This guide covers the organization, security feature, and tooling setup required for the Secure by Design Guardrails workshop.

4.1 Organization & Repository Setup

Path A: Continuing from Workshop 1 (recommended)

If you completed WS1, verify your existing environment: 1. **Confirm your organization** exists on GHE.com (Japan region) 2. **Confirm your repository** exists within the organization 3. **Confirm EMU identities** are provisioned and assigned to the organization 4. **Confirm branch protections** are configured (access control from WS1) ```bash # Verify repository access gh repo view / --json name,owner,defaultBranchRef ``` </details>

Path B: Standalone Setup (if skipping WS1)

1. **Create an organization** on GitHub Enterprise Cloud with Data Residency (Japan region) 2. **Create a repository** within the organization (e.g., `secure-app-demo`) 3. **Configure branch protections** on `main`: - Require pull request before merging - Require at least 1 approval - Do not allow bypassing the above settings ```bash # Create and clone the repository gh repo create /secure-app-demo --private --clone cd secure-app-demo ``` </details> **Create a feature branch** for the workshop exercises: ```bash git checkout -b workshop/secure-by-design ``` --- ## 4.2 Full GHAS Activation This is the **core setup** for Workshop 2 — enabling the detection and prevention capabilities that power our guardrails. 1. Navigate to your repository → **Settings** → **Code security** 2. Enable each capability: | Capability | Setting | Location | |------------|---------|----------| | **Code scanning (CodeQL)** | Default setup → Enable | Code security → Code scanning | | **Secret scanning** | Enable | Code security → Secret scanning | | **Push protection** | Enable | Code security → Secret scanning → Push protection | | **Dependency review** | Automatic (enabled with dependency graph) | Code security → Dependency graph | > [!IMPORTANT] > All four capabilities must be enabled before proceeding. CodeQL's initial analysis may take several minutes — trigger it now so results are ready for Exercise 2. 3. **Trigger initial CodeQL scan** (if not already running): - Navigate to **Actions** tab → confirm the "CodeQL" workflow is present - If no workflow exists, go to **Settings** → **Code security** → **Code scanning** → click **Set up** → choose **Default** --- ## 4.3 Add Required Status Checks (Policy Layer) > WS1 configured branch protections as **access control** (who can merge). We're now adding **security policy** on top (what conditions must be met to merge). 1. Navigate to **Settings** → **Branches** → edit your branch protection rule for `main` 2. Enable **Require status checks to pass before merging** 3. Add the following required checks: - `CodeQL` (or the name of your code scanning check) 4. Save changes ``` WS1 Branch Protections (Access Control) ├── Require pull request ├── Require 1 approval └── No bypass allowed + WS2 Additions (Security Policy) ← NEW └── Require status checks to pass └── CodeQL must pass ``` --- ## 4.4 Copilot Agent Setup 1. Navigate to **Organization Settings** → **Copilot** → **Policies** 2. Enable **Copilot coding agent** for the organization 3. Enable **Copilot Autofix** for security alerts 4. **Important constraint**: Ensure that Copilot coding agent **cannot merge directly to `main`** — human review is required > [!TIP] > Optionally, configure custom instructions (`.github/copilot-instructions.md`) with secure coding guidelines for your project. Copilot will reference these when suggesting fixes. --- ## 4.5 Prepare Vulnerable Code Samples The `vulnerable-samples/` directory contains intentionally vulnerable files for the exercises. These are committed to a **feature branch only** — never to `main`. | File | Vulnerability Type | Triggers | |------|--------------------|----------| | [`secret-leak.js`](https://github.com/shinyay/agentic-devsecops-secure-by-design/blob/main/vulnerable-samples/secret-leak.js) | Hardcoded API key | Push protection | | [`sql-injection.js`](https://github.com/shinyay/agentic-devsecops-secure-by-design/blob/main/vulnerable-samples/sql-injection.js) | SQL injection via string concatenation | CodeQL code scanning | | [`package.json`](https://github.com/shinyay/agentic-devsecops-secure-by-design/blob/main/vulnerable-samples/package.json) | Vulnerable dependency (`lodash@3.10.1`) | Dependency review | ```bash # Add vulnerable samples to your feature branch cp -r vulnerable-samples/ . git add vulnerable-samples/ git commit -m "Add vulnerable samples for workshop exercises" ``` > [!CAUTION] > These files contain **fake credentials and intentionally insecure code** for educational purposes only. Never commit real secrets or use these patterns in production. --- ## Repository Structure ``` agentic-devsecops-secure-by-design/ ├── README.md # Workshop guide ├── THREAT-MODEL.md # Living threat model (Warm-Up) ├── vulnerable-samples/ │ ├── secret-leak.js # Fake API key (Exercise 2a) │ ├── sql-injection.js # SQL injection (Exercise 2b) │ └── package.json # Vulnerable lodash (Exercise 2c) ├── .devcontainer/ │ └── devcontainer.json # Codespaces configuration ├── scripts/ │ ├── verify-setup.sh # Verify environment prerequisites │ ├── verify-exercise1.sh # Validate Exercise 1 (Policy) │ ├── verify-exercise2.sh # Validate Exercise 2 (Detection) │ └── verify-exercise3.sh # Validate Exercise 3 (Remediation) └── docs/ ├── detection-worksheet.md # Exercise 2: observation template ├── autofix-evaluation.md # Exercise 3A: quality rating template └── security-campaign-tracker.md # Exercise 3B: campaign tracking ``` --- ## Verify Setup Run the verification script to confirm your environment is ready: ```bash scripts/verify-setup.sh ``` > [!TIP] > Run `scripts/verify-setup.sh` after completing all setup steps to confirm your environment is ready for the exercises.

← → to navigate between steps