======= ——————————————————–
The cybersecurity industry has spent the last two years exploring how Large Language Models (LLMs) can improve application security workflows. One of the most popular use cases has been automated pull request reviews, where AI analyzes code changes and attempts to identify security issues before they reach production.
While the idea is compelling, a fundamental challenge emerges at scale.
Large organizations don’t operate a handful of repositories. They operate hundreds or thousands of services, shared libraries, internal frameworks, and interconnected systems. Security risks rarely exist in isolation, and reviewing individual pull requests only provides a small piece of the bigger picture.
Cloudflare appears to have encountered this exact limitation.
What began as a security review “Skill” evolved into a much larger system capable of discovering, validating, prioritizing, and remediating vulnerabilities across an organization’s repositories.
Traditional AI-powered pull request reviews typically operate within a limited context:
This works reasonably well for small-scale analysis but becomes increasingly difficult as organizations grow.
Security teams often need answers to broader questions:
Solving these problems requires more than a pull request reviewer.
It requires a workflow.
According to Cloudflare, their original Skill performed automated security reviews against pull requests.
The concept worked, but eventually ran into scalability limitations.
Rather than optimizing the Skill further, they transformed it into an automated pipeline capable of understanding codebases, finding vulnerabilities, validating findings, generating fixes, and routing recommendations to engineers.
A simplified view of the workflow looks like this:
Repository Analysis
│
▼
Vulnerability Discovery
│
▼
Finding Validation
│
▼
Fix Generation
│
▼
Pull Request Creation
│
▼
Human Approval
This approach shifts the focus away from individual pull requests and toward organization-wide security visibility.
One of the most interesting design decisions is that vulnerability detection is not the first step.
Before looking for security issues, the system attempts to understand the application itself.
This stage includes:
Cloudflare described using multiple agents working together during this process.
This mirrors how experienced security engineers typically approach assessments. Understanding architecture and trust boundaries often provides far more value than blindly searching for vulnerabilities.
Without context, findings are frequently noisy.
With context, findings become actionable.
After building architectural awareness, the system begins actively searching for vulnerabilities.
This stage includes:
The objective is not simply to generate a large number of findings.
The objective is to identify findings that are relevant, actionable, and worth an engineer’s time.
Anyone who has worked with security scanners understands that reducing false positives is often more valuable than generating additional alerts.
One particularly interesting design choice is the use of a separate model for validation.
Rather than relying entirely on the original model’s conclusions, Cloudflare introduces a second validation stage.
Model A
Discovers Findings
│
▼
Model B
Validates Findings
The second model attempts to verify reported vulnerabilities and increase confidence in the results.
This separation helps reduce situations where a model reinforces its own mistakes and introduces an additional layer of quality control before findings reach engineers.
Many security tools stop after generating reports.
Cloudflare’s workflow continues further.
Once findings are validated, the system attempts remediation by:
This transforms the system from a vulnerability detection platform into an engineering assistant.
The difference is significant.
A finding accompanied by a tested pull request is far more likely to be addressed than a finding buried inside a report waiting for manual remediation.
Despite the heavy use of automation, humans remain part of the decision-making process.
Cloudflare routes generated pull requests through a Human-in-the-Loop (HITL) workflow.
Engineers can:
This model preserves accountability while still benefiting from automation.
The goal is not to replace security engineers.
The goal is to increase their effectiveness.
Cloudflare shared statistics from a run involving more than 100 repositories.
After automated filtering and prioritization:
Following review by development and security teams:
These numbers highlight a reality many security teams already understand:
Finding vulnerabilities is rarely the hardest problem.
Filtering noise is.
The most interesting aspect of this workflow is not the use of AI itself.
Many organizations are experimenting with AI-powered security tooling.
What makes Cloudflare’s approach notable is the structure surrounding the models.
Instead of building a smarter scanner, they built a system capable of:
This is likely closer to the future of practical AI security engineering than a single all-knowing security model.
Security teams often focus heavily on detection.
Cloudflare’s workflow demonstrates the value of optimizing the entire lifecycle instead.
A vulnerability only becomes meaningful when it can be trusted, prioritized, remediated, and ultimately resolved.
The organizations that successfully integrate AI into security operations will likely be those that focus less on individual models and more on designing scalable workflows around them.
For security engineers, that may be the most important lesson of all.
Practical guide for security engineers to automate auditing scripts that detect and remediate configuration drift in cloud and on-prem environments....
Comprehensive guide to understanding, securing, and hardening AI/ML pipelines in both open-source and cloud environments for security engineers.
Comprehensive guide to building secure and hardened CI/CD pipelines using GitHub Actions and GitLab CI/CD for DevSecOps teams.
Hands-on guide for engineers to implement secure GitHub organizational access & secrets management at scale.
A focused guide on securing Terraform infrastructure-as-code, covering state file protection, least privilege, secrets management, and guardrail automation
Stay curious. Keep building.
Evilginx2 is an adversary-in-the-middle phishing framework that works as a reverse proxy between a victim and a legitimate website. Instead of creating a fake login page, it transparently forwards traffic to the real site while sitting in the middle. This allows an attacker to capture not only usernames & passwords, but also authenticated session cookies after the user successfully completes multi-factor authN (MFA). With those session tokens, the attacker can access vitim’s account without the need of credentials or the second factor itself.
Attackers use Evilginx2 because it allows them to bypass common MFA protections such as SMS codes or authenticator apps. Since the victim logs in to the real website through the attacker’s proxy, the authN process succeeds normally, and valid session cookies are generated. The attacker can then reuse those session tokens to access the account without triggering another MFA challenge. This makes the attack more effective than traditional phishing pages that only steal usernames and passwords.
:contentReference[oaicite:0]{index=0} operates as a reverse proxy between the victim and the legitimate website. When the victim accesses the phishing domain, requests are forwarded to the real site and responses are relayed back. This makes the session appear authentic because the user interacts with the genuine application, while the proxy transparently intermediates traffic.
Configuration defines how the proxy handles domains and traffic routing. Phishlets are configuration files that describe how authN flows should be intercepted and how session data is extracted.
sudo apt install evilginx2/etc/hosts file and add your domain, ip, subdomains (if any).vim /usr/share/evilginx2/phishlets/office365.yamlevilginx2 --developer and config domain, IP, and phishlet:
config domain <your domain>config ipv4 <your ip>phishlets hostname <phishlet name> <your domain>phishlets enable <phishlet name>phishlets command to ensure the new phishlet is enabled and configuredlures create <phishlet name>lures get-url <phishlet index number>
During the login process, credentials submitted by the victim pass through the proxy before reaching the target service. Evilginx logs these creds as they transit. Since authN is processed by the real site, there are no obvious signs of compromise from the victim’s perspective. Nevertheless, the user will be redirected back to the real serive login page - prevent any suspicious from the victim that anything actually happened.
After successful authN, modern web apps issue session cookies that represent the authenticated state. Because the proxy handles traffic, it can capture these cookies as they are issued by the legitimate server. These session tokens are valuable as they allow account access without requiring password or MFA.
With a valid session cookie, an attacker can import the token into their own browser session and impersonate the victim. The server treats the session as authenticated because the token remains valid. This enables account access until the session expires or is revoked by the user or security controls.
Since AiTM attacks bypass MFA by stealing valid session tokens, defense must focus on phishing-resistant authN and strong session controls.
AiTM attacks are effective against password and token-based authN, but they fail against phishing-resistant MFA such as FIDO2/WebAuthn, where creds are cryptographically bound to the legitimate domain. They also rely on users clicking malicious links, which strong in-house phishing awareness programs can reduce. Short session lifetimes, device binding, and continuous session monitoring further limit the attack window by quickly invalidating stolen tokens.
AiTM demonstrates how to bypass traditional MFA by targeting session tokens instead of passwords. The technique highlights a key security gap: authN alone is not enough if session handling is weak. Orgs should move toward phishing-resistant MFA, strong session controls, and continuous monitoring to reduce the real-world impact of these attacks.
A breakdown of the rising crypto investment scams known as 'Pig Butchering' how they work, red flags to watch for,...
Modern attacks target sessions, not just passwords.
Modern infrastructure (whether cloud-based, on-prem, or hybrid) is dynamic. Configuration changes happen constantly: developers update services, engineers tweak network rules, or automated scripts adjust system settings. While these changes are often intentional, they might introduce configuration drift - a divergence between the desired state defined in your code or policy and the actual state of your infrastructure.
For security engineers, configuration drift is not just an operational concern — it’s a critical security risk. Config drifts may lead to:
Manual detection of drift across multiple environments is time-consuming and error-prone. Automated auditing scripts and CI/CD integrations are essential to detect, report, and remediate drift quickly, maintaining security, compliance, and operational consistency.
In this post, I’ll explore:
By reading this post till the end, you can have a structured approach to “drift no more”, ensuring infrastructure stays aligned with policy and security expectations.
Configuration drift happens when the real setup of your systems slowly changes from what you originally planned or approved. Even small changes—an extra security group rule, a new IAM permission, a disabled logging setting—can push your environment away from its secure baseline.
Drift usually appears because of:
When drift builds up, you lose control and visibility. Systems that were once secure can become exposed, misconfigured, or non-compliant without anyone noticing.
This is why drift is a real security risk: attackers often exploit misconfigurations that teams did not know existed. Detecting and fixing drift early keeps your environment aligned with the security rules you intended.
Configuration drift is not only an operational problem. It is also a security risk. When systems slowly change from their approved state, they can become easier to attack.
Unexpected open ports or services
A server may start running something that was not part of the plan. Attackers may use it.
Changed permissions
Users or processes may get more access than they should, creating privilege-escalation paths.
Disabled security controls
Logging, firewall rules, or monitoring agents may be turned off without anyone noticing.
Unpatched or inconsistent versions
Some machines may miss updates. Attackers look for these weak points.
Harder investigations
If every machine is different, it becomes harder to understand alerts or reproduce incidents.
Drift detection helps keep systems predictable, hardened, and safe.
Automated auditing is the process of continuously checking systems, configurations, and infrastructure against a known-good baseline. The goal is to detect drift early, reduce manual work, and keep environments consistent and secure.
Baseline Definition
A baseline is the approved configuration. It can be a Terraform state file, an Ansible playbook, a Kubernetes manifest, or a simple JSON/YAML policy file.
State Comparison
The collected state is compared with the baseline.
Differences indicate drift.
Policy Enforcement
Some auditing systems use policies (like OPA or AWS Config Rules) to define what is allowed and what is not.
Continuous Monitoring
Automated audits run on a schedule (every X minutes/hours) or event-driven (e.g., on deployment).
Alerting and Reporting
When drift is found, the system sends alerts through Slack, email, SIEM, or ticketing systems.
Automated auditing creates a feedback loop that keeps infrastructure consistent, compliant, and secure.
Selecting the right tools is crucial for effective drift detection and automated auditing. Tools should help you compare the current state of your infrastructure or configurations against the desired state, provide clear reporting, and ideally allow for remediation.
Several open-source tools are widely used in the security and DevOps community:
Terraform + terraform plan
Detects differences between deployed infrastructure and Terraform configuration.
Can be integrated into CI/CD pipelines for automated checks.
Example:
terraform init
terraform plan -out=plan.out
terraform show -json plan.out
InSpec (by Chef)
Allows writing tests for infrastructure configurations in a human-readable way.
Can check servers, cloud resources, and more.
Example:
describe aws_s3_bucket('my-bucket') do
it { should exist }
it { should_not be_public }
end
Ansible + ansible-playbook --check
Simulates configuration changes without applying them.
Useful for detecting drift in server or application configurations.
Example:
ansible-playbook playbook.yml --check
Cloud providers offer native services for configuration monitoring:
AWS Config
Continuously monitors AWS resource configurations.
Allows defining rules to detect non-compliant resources.
Example: Detect S3 buckets without encryption.
{
"ConfigRuleName": "s3-bucket-encrypted",
"Source": {
"Owner": "AWS",
"SourceIdentifier": "S3_BUCKET_SERVER_SIDE_ENCRYPTION_ENABLED"
}
}
AWS CloudTrail + CloudWatch
Tracks API activity and changes across AWS services.
Enables alerting when configuration drift occurs.
AWS Systems Manager Compliance
Checks managed instances against a desired state defined by State Manager documents.
Using the right combination of open-source and cloud-native tools ensures you can detect drift across both on-prem and cloud environments, providing full coverage for security engineers.
Automated scripts allow security engineers to continuously monitor infrastructure and configuration drift without manual intervention. The goal is to detect deviations from the desired state and optionally trigger remediation or alerts.
Key principles for effective scripts:
Python is popular for writing drift detection scripts due to its rich ecosystem and cloud SDKs.
## drift_check.py
import boto3
## Initialize AWS S3 client
s3 = boto3.client('s3')
## Desired state: All buckets must have server-side encryption enabled
desired_state = True
## Fetch all S3 buckets
buckets = s3.list_buckets()['Buckets']
for bucket in buckets:
bucket_name = bucket['Name']
try:
enc = s3.get_bucket_encryption(Bucket=bucket_name)
status = True
except s3.exceptions.ClientError:
status = False
if status != desired_state:
print(f"DRIFT DETECTED: Bucket '{bucket_name}' encryption is not enabled!")
Explanation:
For quick audits or integration into CI/CD, shell scripts can be useful:
#!/bin/bash
## Desired: All Docker containers running specific version
DESIRED_IMAGE="nginx:1.25"
for container in $(docker ps --format ''); do
image=$(docker inspect --format='' $container)
if [ "$image" != "$DESIRED_IMAGE" ]; then
echo "DRIFT DETECTED:"
echo "Container $container"
echo "running $image instead of $DESIRED_IMAGE"
echo "---"
fi
done
Explanation:
By creating Python or shell scripts with clear logic and logging, security engineers can detect drift early, before it becomes a vulnerability or compliance issue.
Once drift is detected, the next step is bringing your infrastructure back to the desired state. Key strategies include:
Tip: Always log detected drift and applied fixes. This provides auditability and helps identify recurring issues.
Integrating drift detection into your CI/CD pipelines ensures that infrastructure stays consistent automatically. Key points:
Example: A GitHub Actions job can run a Terraform plan and compare it to the applied state to detect drift before merging changes.
Effective drift detection isn’t just about running scripts—it’s about knowing when something goes wrong and taking action quickly.
Key points:
Preventing drift is always easier than fixing it. Security engineers should follow these key practices:
Following these practices helps minimize surprises, maintain security posture, and reduce operational risks.
Configuration drift is a hidden risk that can silently undermine security and stability. By implementing automated drift detection, integrating checks into CI/CD pipelines, and following best practices for prevention, security engineers can:
“Drift No More” is not just a goal—it’s a continuous practice that keeps your infrastructure secure, consistent, and reliable.
An analysis of Cloudflare's approach to scaling AI-powered security reviews beyond pull requests through automated discovery, validation, remediation, and human-in-the-loop...
Comprehensive guide to understanding, securing, and hardening AI/ML pipelines in both open-source and cloud environments for security engineers.
Comprehensive guide to building secure and hardened CI/CD pipelines using GitHub Actions and GitLab CI/CD for DevSecOps teams.
Hands-on guide for engineers to implement secure GitHub organizational access & secrets management at scale.
Learn Terraform from scratch with this beginner-friendly guide. Step through setup, key concepts, and practical examples—plus grab the ultimate command...
A focused guide on securing Terraform infrastructure-as-code, covering state file protection, least privilege, secrets management, and guardrail automation
Drift detection is not optional—it’s a cornerstone of modern security engineering. — Dan.C
]]>
Artificial Intelligence (AI) and Machine Learning (ML) are revolutionizing software systems and enterprise workflows. But as these systems increasingly influence business-critical operations, security becomes a top concern.
AI pipelines involve data ingestion, model training, validation, deployment, and monitoring. Any compromise along this chain can introduce significant risk, including malicious outputs, stolen intellectual property, or unauthorized access to infrastructure.
This post provides security engineers with a comprehensive, conceptual, and architectural guide to securing AI/ML pipelines in both open-source and cloud environments, focusing on PyTorch/Hugging Face and AWS SageMaker.
Artificial Intelligence (AI) enables machines to perform tasks that traditionally require human intelligence. Machine Learning (ML) is a subset of AI where models learn patterns from data rather than relying on explicit rules.
Why security matters:
Ensuring AI/ML security is about protecting data, models, and the execution environment from both accidental and intentional compromise.
AI pipelines span multiple environments. Understanding them is key to applying the right security measures.
Open-source frameworks such as PyTorch, TensorFlow, and Hugging Face Transformers allow teams to:
Security considerations:
Cloud platforms like AWS SageMaker provide:
Security considerations:
AI pipelines inherit software supply chain risks similar to traditional DevSecOps, with additional AI-specific threats.
Attackers inject malicious or misleading data into training datasets.
requirements.txt or environment.yml.hashicorp/pyup or safety to check for known vulnerabilities.AI and ML pipelines offer immense value but introduce new attack surfaces. Security engineers must consider the entire AI supply chain: from data ingestion to model deployment and endpoint exposure.
By applying least privilege, environment isolation, dependency verification, and continuous monitoring, teams can secure both open-source frameworks and cloud ML platforms while maintaining agility and productivity.
An analysis of Cloudflare's approach to scaling AI-powered security reviews beyond pull requests through automated discovery, validation, remediation, and human-in-the-loop...
Practical guide for security engineers to automate auditing scripts that detect and remediate configuration drift in cloud and on-prem environments....
Comprehensive guide to building secure and hardened CI/CD pipelines using GitHub Actions and GitLab CI/CD for DevSecOps teams.
Hands-on guide for engineers to implement secure GitHub organizational access & secrets management at scale.
A focused guide on securing Terraform infrastructure-as-code, covering state file protection, least privilege, secrets management, and guardrail automation
AI systems are only as secure as the pipelines that build, deploy, and maintain them. — Dan.C
]]>
CI/CD (Continuous Integration / Continuous Deployment) pipelines are the backbone of modern software delivery. They allow teams to build, test, and deploy code automatically, increasing efficiency and reducing errors.
However, pipelines are also high-value attack vectors. If compromised, attackers can:
This guide provides practical, step-by-step instructions for security engineers to secure CI/CD pipelines using GitHub Actions and GitLab CI/CD, from general best practices to platform-specific hardening.
CI/CD is a set of practices that automate software delivery:
Benefits:
Risks if misconfigured:
Before diving into hardening pipelines, let’s compare two primary CI/CD platforms:
.github/workflows/..gitlab-ci.yml.Both platforms allow automation of builds, tests, and deployments, but security configurations and best practices differ slightly. We will cover platform-specific guidance below.
Implement these step-by-step to harden pipelines from scratch:
Implementing this checklist before diving into platform-specific hardening ensures a strong baseline.
GitHub Actions allows automation directly in GitHub, with workflows defined in .github/workflows/.
name: CI Pipeline
on:
push:
branches: [main]
pull_request:
branches: [main]
jobs:
build:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Install dependencies
run: npm ci
- name: Run tests
run: npm test
Explanation:
on: defines events triggering the workflow.jobs: are isolated tasks; runs-on: sets the environment.steps: can run shell commands or call reusable actions.Never store secrets in code. Use GitHub encrypted secrets:
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Configure AWS credentials
uses: aws-actions/configure-aws-credentials@v4
with:
aws-access-key-id: $
aws-secret-access-key: $
Why:
Key security measures:
Use least privilege tokens
Pin third-party actions
uses: actions/checkout@v4 # pinned SHA to prevent supply chain attacks
Restrict branch access
Enable push protection & secret scanning
Limit workflow permissions
permissions:
contents: read # Only read repo content
id-token: write # Only required if using OIDC
Use ephemeral runners or containers
Configured via .gitlab-ci.yml in repo root.
stages:
- build
- test
- deploy
build:
stage: build
image: node:20
script:
- npm ci
- npm run build
artifacts:
paths:
- dist/
test:
stage: test
image: node:20
script:
- npm test
dependencies:
- build
deploy:
stage: deploy
image: amazon/aws-cli:2.13.3
script:
- aws s3 sync ./dist s3://my-bucket --delete
only:
- main
Explanation:
stages: defines the pipeline order.artifacts: persist outputs between jobs.only: restricts deployment to main branch.GitLab uses CI/CD variables:
deploy:
stage: deploy
script:
- echo "Deploying..."
- aws s3 sync ./dist s3://my-bucket --delete
only:
- main
variables:
AWS_ACCESS_KEY_ID: $AWS_ACCESS_KEY_ID
AWS_SECRET_ACCESS_KEY: $AWS_SECRET_ACCESS_KEY
Best practices:
protected: true to restrict usage to protected branches.Pin Docker images
image: node:20@sha256:<digest>
CI/CD pipelines accelerate software delivery, but speed without security is risky.
By following this guide, security engineers can:
Implementing these practices ensures automation enhances productivity without introducing vulnerabilities.
An analysis of Cloudflare's approach to scaling AI-powered security reviews beyond pull requests through automated discovery, validation, remediation, and human-in-the-loop...
Practical guide for security engineers to automate auditing scripts that detect and remediate configuration drift in cloud and on-prem environments....
Comprehensive guide to understanding, securing, and hardening AI/ML pipelines in both open-source and cloud environments for security engineers.
Hands-on guide for engineers to implement secure GitHub organizational access & secrets management at scale.
A comprehensive beginner-friendly guide to the most important threat modeling frameworks in cybersecurity.
A focused guide on securing Terraform infrastructure-as-code, covering state file protection, least privilege, secrets management, and guardrail automation
Fast delivery shouldn’t mean fragile security. — Dan.C
]]>
GitHub is the backbone of many organizations’ development lifecycle. But without hardened access control and secrets management, it quickly becomes the weakest link in your DevSecOps chain.
This post provides practical best practices with real CLI, API, and Terraform configurations, showing how to build a GitHub org security baseline that can scale.
At its core, access control is about answering one simple question:
👉 “Who is allowed to do what inside my GitHub organization?”
GitHub provides multiple layers of access control that work together. Think of it like doors in a building — some people can only enter the lobby, some can access specific floors, and only a few hold the master keys.
If you’re starting with a brand new GitHub org, here’s a practical workflow you can follow.
backend, frontend, devops, security).write, security team = admin only where needed.backend, frontend, devops, security).triage or read where possible.write only where absolutely needed.CODEOWNERS to enforce reviews.CLI Example:
gh api -X PUT \
/orgs/ORG/teams/security/memberships/<USERNAME> \
-f role=member
Manual clicks don’t scale. Automation ensures consistency, auditability, and compliance.
gh) → scripting and audits.Example: Terraform team + repo assignment
resource "github_team" "security" {
name = "security"
description = "Security team"
}
resource "github_team_repository" "security_repo_access" {
team_id = github_team.security.id
repository = "critical-service"
permission = "admin"
}
Replace static cloud credentials with short-lived OIDC tokens.
AWS Example
permissions:
id-token: write
contents: read
jobs:
deploy:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Configure AWS creds via OIDC
uses: aws-actions/configure-aws-credentials@v4
with:
role-to-assume: arn:aws:iam::123456789012:role/GitHubActionsRole
aws-region: eu-central-1
Get last 100 audit events Endpint should be - “https://api.github.com/orgs/ORG/audit-log?per_page=100&include=web,repo,team”
curl -H "Authorization: Bearer $GITHUB_TOKEN" "<endppoint>"
Monitor for:
GitHub org security isn’t a one-time setup — it’s a continuous process. By combining least privilege, secrets hygiene, and automation, DevSecOps teams can stay ahead of attackers and scale securely.
An analysis of Cloudflare's approach to scaling AI-powered security reviews beyond pull requests through automated discovery, validation, remediation, and human-in-the-loop...
Practical guide for security engineers to automate auditing scripts that detect and remediate configuration drift in cloud and on-prem environments....
Comprehensive guide to understanding, securing, and hardening AI/ML pipelines in both open-source and cloud environments for security engineers.
Comprehensive guide to building secure and hardened CI/CD pipelines using GitHub Actions and GitLab CI/CD for DevSecOps teams.
A focused guide on securing Terraform infrastructure-as-code, covering state file protection, least privilege, secrets management, and guardrail automation
The cost of hardening today is less than the cost of recovering tomorrow. — Dan.C
]]>
Imagine you’re building a banking app. You’ve encrypted passwords, secured the database, and applied patches. But have you really thought like an attacker? What if someone tries to spoof a user, escalate privileges, or exploit an overlooked vulnerability?
That’s where threat modeling frameworks come in. They give security teams structured ways to anticipate, prioritize, and mitigate threats—long before attackers exploit them. In this guide, we’ll explore the most widely used frameworks: STRIDE, MITRE ATT&CK, PASTA, CVSS, and TMaaC.
Threat modeling is a structured process for identifying what can go wrong in a system and how to defend against it.
Think of it like architecture: when designing a building, architects consider earthquakes, fire hazards, and break-ins. In cybersecurity, we consider spoofing, denial of service, and privilege escalation.
Different frameworks provide different perspectives: some focus on attacker behavior, some on risk scoring, and some on automation.
| Framework | Goal | Strength | Best For | Example Use Case |
|---|---|---|---|---|
| STRIDE | Identify threat categories | Simple, systematic | Developers | Designing a login system |
| MITRE ATT&CK | Map attacker behaviors | Real-world focus | SOC/Blue Teams | Phishing detection |
| PASTA | Risk-based simulation | Business alignment | Enterprises | E-commerce site analysis |
| CVSS | Score vulnerabilities | Global standard | Security managers | Patch prioritization |
| TMaaC | Automate threat modeling | DevSecOps-friendly | Agile teams | CI/CD threat integration |
No single framework solves everything. Instead, they complement each other:
Together, these frameworks form a toolbox for thinking like an attacker, defending like a pro, and scaling security across teams.
Back to our banking app—would you start with STRIDE to identify possible threats, or rely on MITRE ATT&CK to map out attacker behaviors?
The right answer depends on context. The important thing is knowing that frameworks exist to guide you through the complexity of cybersecurity.
If you’re new, start small with STRIDE or CVSS. As your security practice matures, explore MITRE ATT&CK, PASTA, and TMaaC.
Comprehensive guide to building secure and hardened CI/CD pipelines using GitHub Actions and GitLab CI/CD for DevSecOps teams.
The earlier you model threats, the stronger your defenses will be. — Dan.C
]]>
If you’ve ever manually clicked through a cloud console to create servers, databases, or networks, you know it can get messy fast. What if you need to replicate the same environment tomorrow, or share it with your team? That is where Terraform comes in.
This post is your from zero to hero guide:
Terraform is an Infrastructure as Code (IaC) tool. Instead of manually creating resources in AWS, Azure, GCP, or other providers, you describe your infrastructure in declarative configuration files.
Imagine you’re telling a builder:
Terraform’s workflow always revolves around four core commands:
.tf) describing resources.At the end, you can destroy everything with a single command.
Download Terraform from HashiCorp’s official site.
Check installation:
terraform -v
Create a new folder and a file called main.tf.
Inside main.tf, write:
provider "aws" {
region = "us-east-1"
}
resource "aws_s3_bucket" "demo" {
bucket = "my-terraform-demo-bucket-12345"
acl = "private"
}
What this does:
aws_s3_bucket) and a name (demo).terraform init
This downloads the provider plugin (AWS in this case) into a hidden folder .terraform/.
Without init, Terraform doesn’t know how to talk to AWS.
terraform validate
Checks for typos and syntax errors. Think of it as a compiler for your infra.
terraform plan
Shows what Terraform would do:
terraform apply
Terraform now creates your resources. You’ll be asked to confirm with yes.
Behind the scenes, Terraform also updates its state file (terraform.tfstate). This file keeps track of all resources Terraform manages.
When you’re done testing:
terraform destroy
Terraform removes everything it created. This is super useful for keeping cloud costs down!
Instead of hardcoding values, make them dynamic:
variable "region" {
default = "us-east-1"
}
provider "aws" {
region = var.region
}
Run with custom variables:
terraform apply -var="region=eu-west-1"
Show useful information after deployment:
output "bucket_name" {
value = aws_s3_bucket.demo.bucket
}
View outputs:
terraform output
Terraform keeps track of what it manages in terraform.tfstate.
Think of modules like functions in programming. They package resources into reusable blocks.
Example:
module "network" {
source = "./modules/network"
cidr_block = "10.0.0.0/16"
}
This lets you structure large projects cleanly.
Workspaces let you separate environments (dev, staging, prod) while reusing the same configs.
terraform workspace new dev
terraform workspace select dev
terraform apply
Here’s your quick reference. Bookmark this!
terraform init # Initialize directory (downloads providers)
terraform validate # Validate configuration files
terraform fmt # Auto-format .tf files
terraform providers # Show required providers
terraform plan # Preview changes (dry run)
terraform apply # Apply changes
terraform destroy # Destroy all managed infrastructure
terraform state list # List resources in state
terraform state show <resource> # Show details of a resource
terraform state rm <resource> # Remove a resource from state
terraform refresh # Refresh local state from provider
terraform output # Show outputs
terraform apply -var="key=value" # Pass variable at runtime
terraform workspace list # List workspaces
terraform workspace new staging # Create new workspace
terraform workspace select staging # Switch to workspace
TF_LOG=DEBUG terraform plan # Debug logs
TF_LOG=TRACE terraform apply # Very detailed logs
Terraform is a powerful tool for managing infrastructure consistently and safely. The learning curve may feel steep at first, but once you understand the workflow (init → plan → apply → destroy) and how state files work, it becomes second nature.
Start small (like creating a single bucket or VM), then explore variables, modules, and remote state as you grow more confident. And whenever you forget a command—come back to the cheat sheet above.
Related Posts
Practical guide for security engineers to automate auditing scripts that detect and remediate configuration drift in cloud and on-prem environments....
A focused guide on securing Terraform infrastructure-as-code, covering state file protection, least privilege, secrets management, and guardrail automation
A practical reference for essential Linux commands every developer, sysadmin, or security engineer should know—organized for speed, efficiency, and daily...
Keep learning, stay inovative. — Dan.C
]]>
Terraform is a powerful IaC (Infrastructure as Code) tool, but misconfigurations and insecure practices can open doors to serious security breaches. From leaked credentials to over-permissive IAM roles, poor Terraform hygiene is often the root cause of cloud compromise.
This post highlights the key security best practices that I’ve implemented in real-world environments to harden Terraform usage and minimize risk.
Avoid using AdministratorAccess for your Terraform automation or local development.
TerraformDevRole, TerraformProdRole).Tooling Tip:
Use terraform-aws-iam-policy-documents to generate principle-of-least-privilege policies easily.
Terraform’s tfstate contains sensitive information such as:
Best practices:
*.tfstate* to .gitignore and never push to VCS.Automate security scanning of Terraform code before any deployment:
checkov -d .
Integrate these into your CI/CD pipeline and fail builds on high-severity findings.
Avoid deploying different environments into the same workspace or backend.
dev, staging, and prod.prod-db, dev-vpc.Hardcoded secrets can easily leak into version control.
Instead, use:
TF_VAR_)Keep modules modular, secure, and testable:
type, regex, etc.)mainEvery terraform apply should go through:
terraform plan reviewSecurity in Terraform isn’t optional — it’s foundational. Secure state, validated inputs, and least privilege access go a long way toward building safe and scalable infrastructure.
Want more? I’ll soon publish a secure AWS Terraform project template with built-in guardrails and automation.
An analysis of Cloudflare's approach to scaling AI-powered security reviews beyond pull requests through automated discovery, validation, remediation, and human-in-the-loop...
Practical guide for security engineers to automate auditing scripts that detect and remediate configuration drift in cloud and on-prem environments....
Comprehensive guide to understanding, securing, and hardening AI/ML pipelines in both open-source and cloud environments for security engineers.
Comprehensive guide to building secure and hardened CI/CD pipelines using GitHub Actions and GitLab CI/CD for DevSecOps teams.
Hands-on guide for engineers to implement secure GitHub organizational access & secrets management at scale.
Learn Terraform from scratch with this beginner-friendly guide. Step through setup, key concepts, and practical examples—plus grab the ultimate command...
Stay sharp, stay secure. — Dan.C
]]>
Reference guide to the most essential Linux commands — ideal for sys admins, developers, DevOps engineers, and cybersecurity professionals. This cheat sheet will help streamline your command-line workflow.
| Command | Description |
|---|---|
ls |
List contents of the current directory |
ls -l |
List with detailed (long) format |
cd /path/to/dir |
Change current directory |
pwd |
Display present working directory |
mkdir new_folder |
Create a new directory |
rm file.txt |
Remove a file |
rm -r folder/ |
Recursively remove a directory and its contents |
touch file.txt |
Create a new, empty file |
cp source dest |
Copy a file or directory |
mv old new |
Move or rename a file or directory |
| Command | Description |
|---|---|
cat file.txt |
Output file contents to the terminal |
less file.txt |
View file one screen at a time (scrollable) |
head file.txt |
Show the first 10 lines of a file |
tail file.txt |
Show the last 10 lines of a file |
nano file.txt |
Edit file using Nano (beginner-friendly) |
vim file.txt |
Edit file using Vim (advanced editor) |
| Command | Description |
|---|---|
chmod +x script.sh |
Make a script executable |
chmod 755 file |
Set read/write/execute permissions (owner), and read/execute (group, others) |
chown user:group file |
Change file ownership |
| Command | Description |
|---|---|
uname -a |
Show system and kernel information |
top / htop |
Real-time process and system monitoring |
df -h |
Display disk space usage (human-readable) |
free -h |
Show memory usage |
uptime |
Show how long the system has been running |
| Command | Description |
|---|---|
whoami |
Display current logged-in user |
id |
Show user ID (UID), group ID (GID), and groups |
ps aux |
List all running processes |
kill PID |
Terminate a process by its PID |
sudo command |
Run command with superuser privileges |
adduser username |
Add a new user |
passwd username |
Change a user’s password |
| Command | Description |
|---|---|
ip a |
Display network interfaces and IP addresses |
ping domain.com |
Send ICMP packets to test connectivity |
curl https://example.com |
Fetch data from a URL |
netstat -tulpn |
Show active listening ports and services (legacy; use ss for modern systems) |
ssh user@host |
Connect to a remote host via SSH |
| Command | Description |
|---|---|
sudo apt update |
Update package lists |
sudo apt upgrade |
Upgrade installed packages |
sudo apt install package |
Install a new package |
sudo apt remove package |
Remove a package |
| Command | Description |
|---|---|
sudo yum install package |
Install package (YUM) |
sudo dnf upgrade |
Upgrade packages (DNF, successor to YUM) |
| Command | Description |
|---|---|
find / -name file.txt |
Search for a file by name starting from root |
grep 'pattern' file.txt |
Search for a text pattern in a file |
locate file.txt |
Quickly find file paths using an indexed database (updatedb required) |
| Shortcut | Description |
|---|---|
Ctrl + C |
Cancel the current running process |
Ctrl + D |
Logout of terminal or send EOF (End of File) |
Ctrl + R |
Search command history interactively |
!! |
Repeat the last command |
!abc |
Run the most recent command starting with abc |
sudo where administrative privileges are required.
Learn Terraform from scratch with this beginner-friendly guide. Step through setup, key concepts, and practical examples—plus grab the ultimate command...
Stay efficient. Stay secure.