DEV Community: IKER ALBERTO SIERRA RUIZ

Applying Checkov to Terraform as Code – A TFSEC Alternative

IKER ALBERTO SIERRA RUIZ — Fri, 05 Jun 2026 18:21:04 +0000

Static Application Security Testing (SAST) is a critical practice in modern DevSecOps. While tools like SonarQube, Snyk, and Veracode are popular, this article focuses on GitHub CodeQL – a semantic code analysis engine that treats code as a database. We will apply it to a vulnerable Java Spring Boot application to detect SQL Injection and Path Traversal.

🤔 Why CodeQL?

Unlike pattern-based scanners, CodeQL builds a relational database of your code, including abstract syntax trees, control flow graphs, and data flow graphs. This allows it to track tainted data across functions, classes, and files, drastically reducing false positives.

🚨 Target Application (Vulnerable Java App)

Let's look at a simple REST API with two vulnerable endpoints.

File: UserController.java

package com.demo.controller;

import com.demo.model.User;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.jdbc.core.JdbcTemplate;
import org.springframework.web.bind.annotation.*;
import java.nio.file.Files;
import java.nio.file.Paths;
import java.util.List;

@RestController
@RequestMapping("/api")
public class UserController {

    @Autowired
    private JdbcTemplate jdbcTemplate;

    // Vulnerability 1: SQL Injection
    @GetMapping("/users")
    public List<User> getUsers(@RequestParam("id") String userId) {
        String sql = "SELECT * FROM users WHERE id = " + userId; // Dangerous concatenation
        return jdbcTemplate.query(sql, (rs, rowNum) -> 
            new User(rs.getString("id"), rs.getString("name")));
    }

    // Vulnerability 2: Path Traversal
    @GetMapping("/file")
    public String readFile(@RequestParam("filename") String filename) throws Exception {
        return new String(Files.readAllBytes(Paths.get("/var/data/" + filename)));
    }
}

🛠️ Installing and Configuring CodeQL CLI

You can run CodeQL locally to analyze your code before pushing it to a repository.

1. Download CodeQL from GitHub releases:

wget [https://github.com/github/codeql-cli-binaries/releases/latest/download/codeql-linux64.zip](https://github.com/github/codeql-cli-binaries/releases/latest/download/codeql-linux64.zip)

2. Unzip and add to PATH:

unzip codeql-linux64.zip -d ~/tools/
export PATH=$PATH:~/tools/codeql/

3. Create a CodeQL database from your source code:

codeql database create ./codeql-db --language=java --source-root=.

4. Download the standard query suite:

git clone [https://github.com/github/codeql.git](https://github.com/github/codeql.git) ~/codeql-repo

5. Run the analysis:

codeql database analyze ./codeql-db --format=sarif-latest --output=results.sarif ~/codeql-repo/java/ql/src/codeql-suites/java-security-and-quality.qls

📊 Interpreting SARIF Results

The results.sarif file (in JSON format) will reveal the vulnerabilities found. For example:

Rule ID: java/sql-injection
Location: line 18, column 20
Code flow: from user-controlled parameter userId to the SQL query sink.

This confirms a critical SQL Injection vulnerability traced straight to the source.

🚀 CI/CD Integration with GitHub Actions

Running CodeQL locally is great, but automating it is better. Here is how to create a GitHub Actions workflow to scan your code automatically.

File: .github/workflows/codeql-analysis.yml

name: "CodeQL Security Scan"
on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  analyze:
    runs-on: ubuntu-latest
    permissions:
      security-events: write
    steps:
    - uses: actions/checkout@v4
    - uses: actions/setup-java@v4
      with:
        distribution: 'temurin'
        java-version: '17'
    - uses: github/codeql-action/init@v3
      with:
        languages: 'java-kotlin'
        queries: security-extended
    - uses: github/codeql-action/autobuild@v3
    - uses: github/codeql-action/analyze@v3

On every pull request, CodeQL will run and upload the results directly to the "Security" tab of your repository.

⚙️ Custom Queries (Advanced)

Because CodeQL treats your code like a database, you can write custom queries to find specific anti-patterns. For example, to detect the use of printStackTrace():

File: CustomLogging.ql

import java

from MethodCall call, Method m
where m.hasName("printStackTrace") and call.getMethod() = m
select call, "Use of printStackTrace() may expose internal details."

Run it with:

codeql query run CustomLogging.ql --database=./codeql-db

🎯 Conclusion

CodeQL provides deep, semantic SAST analysis. Integrated into CI/CD, it becomes an automated gatekeeper against critical vulnerabilities like SQL Injection and Path Traversal. It is a powerful, enterprise-grade alternative to commercial tools, especially for teams already utilizing the GitHub ecosystem.

Applying Checkov to Terraform as Code: A TFSEC Alternative

IKER ALBERTO SIERRA RUIZ — Fri, 05 Jun 2026 18:10:55 +0000

Infrastructure as Code (IaC) brings version control to infrastructure, but it also introduces the risk of deploying architecture-level misconfigurations at scale. While TFSEC is well known in the community, this article demonstrates Checkov – an open-source static analysis tool with graph-based scanning, over 1,000 built-in policies, and robust support for Terraform, CloudFormation, Kubernetes, and more.

🤔 Why Checkov?

Checkov (developed by Bridgecrew) scans IaC for security and compliance violations. Unlike traditional pattern-based checkers that only look at resources in isolation, Checkov builds a graph of resources and their relationships.

This allows it to detect complex issues, such as an S3 bucket that is set to private but is missing an account-level public access block.

🚨 The Problem: Vulnerable Terraform Configuration

Let's look at a problematic main.tf file. On the surface, it deploys standard AWS resources, but it contains three major security violations:

provider "aws" { region = "us-east-1" }

# Violation 1: Public S3 bucket
resource "aws_s3_bucket" "data_bucket" {
  bucket = "my-company-data-2026"
  acl    = "public-read"   # Checkov: CKV_AWS_18
}

# Violation 2: SSH open to world
resource "aws_security_group" "web_sg" {
  name = "web_sg"
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]   # Checkov: CKV_AWS_5
  }
}

# Violation 3: RDS without encryption
resource "aws_db_instance" "default" {
  allocated_storage = 20
  engine            = "mysql"
  instance_class    = "db.t3.micro"
  storage_encrypted = false   # Checkov: CKV_AWS_16
}

🛠️ Installing and Running Checkov

You can easily install Checkov via Python's package manager or run it directly through Docker.

Install via pip:

pip install checkov

Or use Docker:

docker run --tty --volume "$(pwd):/tf" bridgecrew/checkov --directory /tf

Run the scan in your project directory:

checkov -d .

Sample Output

Checkov instantly identifies the vulnerable configurations and maps them to specific AWS security policies:

Check: CKV_AWS_18: "Ensure the S3 bucket has public access blocks"
        FAILED for resource: aws_s3_bucket.data_bucket
        File: /main.tf:6-10

Check: CKV_AWS_5: "Ensure security groups restrict SSH from 0.0.0.0/0"
        FAILED for resource: aws_security_group.web_sg

Check: CKV_AWS_16: "Ensure all data stored in the RDS is securely encrypted at rest"
        FAILED for resource: aws_db_instance.default

✅ Remediation Steps

To pass the Checkov scan, we need to apply the following fixes to our infrastructure code:

1. Fix the S3 Bucket:
Set the ACL to private and attach a Public Access Block resource.

resource "aws_s3_bucket" "data_bucket" {
  bucket = "my-company-data-2026"
  acl    = "private"
}

resource "aws_s3_bucket_public_access_block" "block" {
  bucket              = aws_s3_bucket.data_bucket.id
  block_public_acls   = true
  block_public_policy = true
}

2. Fix the Security Group: Change cidr_blocks = ["10.0.0.0/16"] to restrict SSH access to an internal network only.

3. Fix the RDS Instance: Set storage_encrypted = true and ensure it references a valid KMS key.

🚀 CI/CD Integration with GitLab CI

Finding vulnerabilities locally is good, but preventing them from being merged is better. Here is how to integrate Checkov into your GitLab CI pipeline by creating a .gitlab-ci.yml file:

stages:
  - validate

checkov-scan:
  stage: validate
  image: bridgecrew/checkov:latest
  script:
    - checkov --directory . --quiet --output cli --soft-fail
  artifacts:
    reports:
      terraform: checkov_report.json
  only:
    - merge_requests
    - main

Pro Tip: We use --soft-fail so the pipeline does not break on violations (it only reports them). Once your team is accustomed to the tool, remove --soft-fail to enforce hard security gates.

⚙️ Custom Policies with YAML

Checkov allows you to write custom organizational rules. For example, if you want to prevent developers from provisioning specific instance types to control costs, you can create a .checkov.yaml config map:

custom-policies:
  - name: "Prohibit t2.micro instances"
    file: custom_policies/prohibit_t2_micro.yaml

Content of prohibit_t2_micro.yaml:

metadata:
  id: CUSTOM_1
  name: "No t2.micro allowed"
  category: "COST_OPTIMIZATION"
definition:
  cond_type: "attribute"
  resource_types: "aws_instance"
  attribute: "instance_type"
  operator: "not_equals"
  value: "t2.micro"

To run Checkov with your new custom policy:

checkov -d . --external-checks-dir ./custom_policies

⏭️ Skipping False Positives

Sometimes, a resource like an S3 bucket needs to be public (e.g., for static website hosting). You can suppress Checkov warnings by adding a simple inline comment inside your Terraform code:

resource "aws_s3_bucket" "data_bucket" {
  # checkov:skip=CKV_AWS_18:This bucket is for public static website hosting
  bucket = "my-public-website"
  acl    = "public-read"
}

🎯 Conclusion

Checkov is a mature, highly active SAST tool for Infrastructure as Code. By integrating it into your CI/CD pipeline, you prevent misconfigurations—like open S3 buckets or unencrypted databases—from ever reaching production.

As a TFSEC alternative, it stands out by offering broader framework support (including Kubernetes, CloudFormation, and Pulumi) and intelligent, graph-based security analysis.

Bulletproof Your Java APIs: Automating Tests with REST-Assured

IKER ALBERTO SIERRA RUIZ — Fri, 05 Jun 2026 17:53:59 +0000

As backend architectures shift increasingly toward microservices, validating the communication between these services is paramount. Relying solely on manual API testing is no longer viable. Developers and QA engineers need frameworks that integrate seamlessly into their codebase and CI/CD pipelines.

According to comprehensive industry reviews of API tools, REST-Assured is a standout open-source tool for Java developers. It is a Java Domain-Specific Language (DSL) specifically designed to simplify testing REST services. One of its most powerful features is its support for the BDD (Behavior-Driven Development) Given/When/Then syntax. This syntax makes test cases incredibly readable, meaning you don't necessarily need to be an HTTP expert to understand what the test is doing. It also integrates seamlessly with automation frameworks like Serenity to generate beautiful reports.

Applying REST-Assured: A Real-World Example
Imagine you are building an e-commerce platform and need to test an endpoint that fetches a user's profile information (GET /api/users/{id}). The API requires a Bearer token for authorization.

Here is how you would apply REST-Assured to automate this test in a real-world Java project:

`import io.restassured.RestAssured;
import io.restassured.http.ContentType;
import org.testng.annotations.Test;
import static io.restassured.RestAssured.given;
import static org.hamcrest.Matchers.*;

public class UserProfileApiTest {

@Test
public void verifyUserProfileDataAndSecurity() {
    // Set the base URI for our API
    RestAssured.baseURI = "https://api.ecommerce-realworld.com";

    // Applying the Given/When/Then BDD approach
    given()
        .header("Authorization", "Bearer valid_secure_token_here")
        .contentType(ContentType.JSON)
        .pathParam("userId", "1045")
    .when()
        .get("/api/users/{userId}")
    .then()
        .log().ifValidationFails() // Good practice for debugging CI/CD failures
        .statusCode(200)
        .body("id", equalTo(1045))
        .body("email", equalTo("customer@example.com"))
        .body("role", equalTo("PREMIUM_USER"))
        .body("data.preferences", hasItem("electronics")); // Validating JSON arrays
}

REST-Assured empowers developers to write powerful, maintainable API tests right alongside their production Java code. By leveraging its baked-in functionalities, teams can avoid coding complex HTTP clients from scratch, ensuring their microservices remain robust, secure, and reliable with every deployment.

Mastering API Testing with Postman: A Real-World Automation Guide

IKER ALBERTO SIERRA RUIZ — Fri, 05 Jun 2026 17:49:45 +0000

In today’s fast-paced software development lifecycle, API testing is a non-negotiable part of any effective CI/DevOps process. It focuses on determining if your built APIs fulfill expectations for functionality, dependability, performance, and security. While there are many tools available, finding the right balance between usability and power is key.

As highlighted in recent industry reviews of top API testing tools, Postman consistently ranks in the top three. Originally a simple Chrome browser plugin, it has evolved into a robust native application for Mac, Windows, and Linux. What makes Postman exceptional is its rich interface and low barrier to entry—you don't need an integrated development environment (IDE) or deep programming knowledge to start. Furthermore, it enables teams to easily share knowledge by packaging requests and expected responses into collections.

Applying Postman: A Real-World Example
Let’s look at a common real-world scenario: testing an authentication endpoint (/api/v1/login). We need to ensure that the API returns a 200 OK status and provides a valid JSON Web Token (JWT) that we can use for subsequent requests.

In Postman, you can automate this validation using JavaScript in the "Tests" tab of your request:

Verify that the response status is 200 OK
pm.test("Status code is 200", function () { pm.response.to.have.status(200); });
Validate that the response time is less than 500ms for performance
pm.test("Response time is acceptable", function () { pm.expect(pm.response.responseTime).to.be.below(500); });
Extract the token and set it as an environment variable for future requests
`pm.test("Response contains JWT token", function () {
var jsonData = pm.response.json();

// Assert the token property exists
pm.expect(jsonData).to.have.property('token');

// Dynamically save the token to the environment
pm.environment.set("jwt_token", jsonData.token);
console.log("Token saved successfully for next API calls.");
});`

By utilizing Postman's built-in testing snippets and environment variables, testing teams can create automated, dynamic workflows without writing complex code from scratch. Whether you are doing exploratory testing or integrating with a CI/CD pipeline, Postman provides a reliable, user-friendly gateway to API quality assurance.