🔄 Topic

Understanding automated deployment as a privileged operational workflow.

🎯 Goal

Learn how GitHub Actions and GitHub Pages turn repository changes into production changes.

🛠 What I Did

I reviewed the deployment model for the Farina website. The project uses GitHub Pages with a GitHub Actions workflow. The workflow installs dependencies, builds the Vite app, checks important deployment requirements such as the CNAME, uploads the dist folder, and publishes the site. This is convenient, but it also means the CI/CD pipeline is a trust boundary. If the workflow or repository is compromised, production can be affected.

Main areas covered:

  • GitHub Actions workflow
  • npm dependency install
  • Vite production build
  • dist artifact upload
  • GitHub Pages publish
  • CNAME verification

🔗 Key Cybersecurity Connections

CI/CD matters because it can become a direct path from code change to public website compromise. Defenders must understand how code reaches production.

🔍 Investigation Questions

  • Who can push to deployment branches?
  • Which workflow files can change deployment behavior?
  • Are secrets exposed to workflows?
  • Does the build output match expectations?
  • Can a pull request modify deployment scripts?

🚨 Detection Opportunities

Potential monitoring ideas:

  • unexpected workflow modification
  • manual workflow run by unusual actor
  • deployment outside normal pattern
  • CNAME missing from build output
  • dependency install executing unexpected scripts

Example:

project=farina-farm-website
change_type=public_website_update
risk_area=repository_deployment_or_public_input
triage=review_change_intent_and_validate_build

🧭 MITRE ATT&CK Techniques

Possible mappings depending on confirmed behavior:

  • T1195 — Supply Chain Compromise
  • T1078 — Valid Accounts
  • T1552 — Unsecured Credentials

🗺 Visual Investigation Diagram

Commit
    ↓ GitHub Actions
    ↓ Dependency install
    ↓ Build
    ↓ Artifact
    ↓ GitHub Pages deployment

⚠ Challenges

The challenge was realizing that automation is not automatically safe. Automation repeats exactly what it is allowed to do, including bad changes.

📚 What I Learned

I learned that CI/CD is production infrastructure. It needs permissions, review, and validation like any other sensitive system.

➡ Next Steps

  • Review workflow permissions
  • Protect deployment branches
  • Run local build before push
  • Keep workflow files simple

🧠 Reflection

This was useful because it turned a real project into security-aware learning without pretending that every task was a pure cybersecurity lab.

🧩 Lessons Learned

What worked

Viewing deployment as a security boundary.

What broke

Thinking GitHub Pages is too simple to worry about.

Why it broke

Static deployment can still be compromised through the build path.

Fix / takeaway

Protect the path from commit to production.

📈 Skill Progression Context

This supports SOC and detection engineering because CI/CD telemetry is increasingly important in modern compromise investigations.

😄 TL;DR

Deployment automation is powerful and privileged.