The GRC Vibe Coder's Playbook · Lesson 05 of 10

How Do I Build and Release More Securely?

Plan for security, put checks in the repo, and review exposure before release.

All 10 Lessons · Jump to a Lesson

Our Running Project

Our vendor risk tool starts with fictional answers and a small scoring function. That keeps the first version manageable, but security still belongs in the plan. Real vendor questionnaires can contain confidential information.

Adding uploads, stored evidence, or integrations later changes what we need to protect. Now that GitHub holds the project record, we can make those boundaries visible, introduce repeatable checks, and prepare a focused security review before sharing a release.

Security Changes as Your Project Grows

Security starts with deciding what to build and what information to use. It continues when you create the repository, add features, prepare a release, and maintain the tool. The tasks change because the system's exposure changes.

Our first vendor risk scorer uses fictional answers. It does not need real questionnaires, credentials, accounts, or a database. If a later version stores evidence or connects to another service, revisit the design before adding those features.

A Security Task for Each Phase

Phase	Security Tasks	In Our Vendor Risk Tool
Planning	Identify sensitive data, intended users, access boundaries, and one way the tool could be misused. Turn those concerns into requirements.	Use fictional answers. Decide who may change scoring rules and what version one will avoid storing.
Repository setup	Check visibility and access, protect credentials, limit automation permissions, and establish dependency updates and reviewed changes.	Keep real evidence and API keys out of GitHub. Configure applicable Dependabot features and run tests on proposed changes.
Development	Validate inputs and revisit security when a feature changes data flows or permissions. Give agents only the access their tasks require.	Treat missing answers explicitly. Before adding uploads or integrations, consider who can read the data and where it goes.
Before release	Review the code and deployment assumptions, apply agreed hardening, verify fixes, and document unresolved risks and recovery steps.	Review report exports, dependency alerts, and access to scoring configuration. Identify the reviewed version and how to restore the previous one.
After release	Assign ownership, respond to alerts, review access, and repeat checks when the system changes.	Test dependency updates and revisit protections when adding stored evidence or a new integration.

Give Your Repository a Small Security Baseline

Start with a few choices you can explain. Select public or private visibility deliberately, enable MFA on your account, and limit collaborators to the access they need. Use branches and pull requests to inspect changes. Require checks or branch rules where your repository and plan support them.

A secret is a credential such as an API key or password. Keep secrets out of source code, examples, logs, and AI prompts. Use your platform's secret storage or environment configuration when credentials are needed. A .gitignore file can keep an untracked local file out of a commit, but it does not remove a secret already committed. Revoke or rotate an exposed credential and investigate its use.

Apply least privilege to agents and GitHub Actions too. A review task usually does not need permission to merge, deploy, or change repository settings. Ask the agent to explain which permissions the work requires before granting them.

A short threat model can start with three questions: what are we protecting, what could go wrong, and which small design choice reduces that risk? For our scorer, an unauthorized change to scoring rules could produce misleading vendor decisions even without a leaked password.

Start with Dependabot: A Free Tool You Already Have Access To

Dependabot helps maintain the external packages and supported GitHub Actions your project uses. Its standard alerts, security updates, and version updates are available on GitHub Free, including public and private repositories. You do not need to buy GitHub's additional security products to use these standard features.

These three features do different jobs:

Alerts identify dependencies with known vulnerabilities.
Security updates attempt to open pull requests that update vulnerable dependencies to patched versions.
Version updates propose routine updates on a schedule, including updates that are not security fixes.

Use the official Dependabot quickstart to enable the applicable features. Version updates use a .github/dependabot.yml file. Security updates can work without that file when their repository setting is enabled.

Read the Configuration One Setting at a Time

Peachtree Demo's answers from Lesson 2 are fictional. A dependency check protects a different part of the project: the external packages used by the tool. It will not catch a rule that incorrectly treats a missing answer as Low Risk. We inspect that behavior in Lesson 7.

You do not need to read this configuration perfectly. Your first goal is to find what gets updated, where Dependabot looks, and how often it checks. YAML is a text format for settings; indentation groups related settings together. Ask an AI or a peer to explain one unfamiliar setting at a time.

For a Python version of our tool with a supported dependency file, such as requirements.txt, at the repository root, save this as .github/dependabot.yml:

1version: 22updates:3  - package-ecosystem: "pip"4    directory: "/"5    schedule:6      interval: "weekly"7    open-pull-requests-limit: 3

version: 2 identifies the configuration format, not your application version.
package-ecosystem: "pip" tells Dependabot to check supported Python dependencies.
directory: "/" points to the repository root, where this example keeps its dependency file.
interval: "weekly" asks for a weekly check.
open-pull-requests-limit: 3 limits open version-update PRs from this entry. It is not a limit on vulnerabilities or security-update PRs.

This example schedules version updates; it does not enable the separate alerts and security-update settings. Match the ecosystem and directory to your project. A JavaScript tool may use npm. Our small Python scoring function uses no external packages, so it does not need a dependency merely to make this example work. Add applicable checks when your project actually uses supported dependencies. If you use GitHub Actions, add a separate github-actions entry for workflow updates.

Before adding the file, ask your coding agent to identify the existing dependency files and explain which entries apply. Then inspect the resulting PRs and check whether their changes work with your tool.

Read update PRs, run your tests, and review compatibility before merging. Keep a reason when you defer a fix. An empty alert list is useful information about the dependencies checked, not a complete assessment of application security. Dependabot will not determine whether your scoring rules or access controls are correct.

GitHub documents that standard Dependabot jobs do not consume included Actions minutes. Tests triggered by an update PR have their own usage accounting. Larger runners and other security products can have separate costs. Check runner guidance and feature availability before promising a completely free workflow.

Ask AI for a Review Before Asking It to Fix Everything

A security review examines how a system could expose information, permit misuse, or fail its security requirements. Name the commit or change being reviewed and describe where the tool will run. Ask for evidence, safe verification steps, and the areas the agent could not check.

For our tool, include input handling, exported reports, dependencies, secrets, scoring-rule access, and workflow permissions. Review hypothetical future accounts or integrations as design questions; do not report them as implemented features.

The prompt below requests a read-only review. Verify its findings before asking for changes. An agent can miss a problem or raise a concern that does not apply to your deployment. Combine its analysis with relevant scans, tests, and human judgment.

Harden the Version You Intend to Release

Hardening reduces unnecessary exposure and strengthens the system for its intended use. It might remove debug output, restrict access, validate inputs, or reduce permissions. It is easier when security boundaries were part of the original plan.

A release identifies a version made available for use. Deployment puts a version into an environment. A GitHub Release does not automatically deploy your application.

After checking the review findings, give the coding agent a bounded follow-up:

Implement only the security findings we agreed to address, on a branch. Preserve the documented scoring rules. Add regression checks for the fixes and run the relevant existing checks. Explain any dependency or permission change before making it. Do not include credentials in the output, merge, create a release, or deploy. Report remaining risks and what could not be verified.

Inspect the resulting diff and evidence. Record the reviewed commit, who made the decision, unresolved findings, and the rollback approach. If a fix changes scoring behavior, update and review the scoring requirements as part of that change.

Then continue with maintenance after launch. Alerts, dependency updates, and security decisions still need an owner after the first release.

The GRC Connection

Define the risk, implement proportionate safeguards, verify evidence, and record the human release decision. An automated alert or AI review supports that decision without establishing complete security coverage.

Put It into Practice

Write a short security baseline for your vendor tool. Identify protected data, who may change scoring rules, and one misuse case. In a repository you own, enable applicable Dependabot features or inspect GitHub's demo. Ask an agent for a read-only security review, verify one finding or document a coverage gap, and open a bounded follow-up issue.

What Good Looks Like

A documented security baseline, an appropriate dependency-update setup, and an evidence-backed review with a verified finding or explicit limitation and a next action.

Check the result yourself. Save the decision or next step in GitHub so you can return to it later.