DEV Community: FabrizioPerezPeralta

Testing Management at Speed: Caching and Execution in CircleCI, Bitbucket Pipelines, and GitHub Actions

FabrizioPerezPeralta — Mon, 06 Jul 2026 05:19:12 +0000

Abstract
An automated test suite is the ultimate gatekeeper for your code, but if it takes 20 minutes to run, it destroys developer velocity. While my colleague recently explored the foundational setup of GitHub Actions, GitLab CI, and Jenkins, this article tackles the next major hurdle in CI/CD testing management: execution speed.

Using the same baseline repository (a Node.js Express app with Jest + Supertest), we will compare how three hosted CI platforms—CircleCI, Bitbucket Pipelines, and GitHub Actions—manage dependency caching and environment execution. We will look at real pipeline code to understand how each tool optimizes the feedback loop, and explore where enterprise tools like TeamCity, Tekton, and Harness fit into the testing lifecycle.

The Speed Problem in CI/CD
In any Node.js project, running npm ci often takes longer than running the tests themselves. If you don't manage caching correctly, your CI server downloads hundreds of megabytes of dependencies on every single commit. To compare how different tools solve this, we are giving them the exact same task:

Check out the code.
Restore cached dependencies (if they exist).
Install missing dependencies.
Run the test suite (npx jest --coverage --ci).
Save the coverage artifacts.

Let's look at the actual configuration files side-by-side.

Pipeline 1: CircleCI (The Speed King)
CircleCI is famous in the DevOps world for granular resource allocation and advanced caching mechanisms. Configuration lives in .circleci/config.yml.

YAML
version: 2.1
jobs:
  test:
    docker:
      - image: cimg/node:22.0    # CircleCI's optimized Node image
    steps:
      - checkout
      # 1. Look for a cache matching the exact package-lock.json
      - restore_cache:
          keys:
            - v1-deps-{{ checksum "package-lock.json" }}
            - v1-deps-

      - run: npm ci

      # 2. Save the cache for future runs
      - save_cache:
          paths:
            - ~/.npm
          key: v1-deps-{{ checksum "package-lock.json" }}

      - run: npx jest --coverage --ci

      - store_artifacts:
          path: coverage/

What stands out: Explicit control. CircleCI forces you to define exactly how your cache is keyed using checksums. If package-lock.json changes, the cache is busted automatically. Furthermore, CircleCI provides cimg/ (convenience images) which are specifically pre-configured Docker images designed to boot up in milliseconds, shaving crucial seconds off your testing pipeline compared to standard Docker Hub images.

Pipeline 2: Bitbucket Pipelines (The Zero-Config Approach)
For teams heavily invested in Jira and the Atlassian ecosystem, Bitbucket Pipelines offers a highly integrated, YAML-based approach that prioritizes simplicity over granular control. Configuration lives in bitbucket-pipelines.yml.

YAML
image: node:22

pipelines:
  default:
    - step:
        name: Build and Test API
        caches:
          - node                # Zero-config dependency caching
        script:
          - npm ci
          - npx jest --coverage --ci
        artifacts:
          - coverage/**

What stands out: Extreme brevity. Notice the caches: - node block. Unlike CircleCI or GitLab CI, where you must define paths and lockfile checksums, Bitbucket Pipelines has pre-defined caching logic for major package managers. It automatically knows that "node" means hashing package-lock.json and caching ~/.npm and node_modules. It is less flexible than CircleCI, but incredibly fast to set up.

Pipeline 3: GitHub Actions (The Balanced Marketplace)
As demonstrated in the baseline repository, GitHub Actions strikes a middle ground between CircleCI's explicit control and Bitbucket's implicit magic, thanks to its reusable actions.

YAML
jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 22
          cache: npm              # The Marketplace action handles the logic

      - run: npm ci
      - run: npx jest --coverage --ci

What stands out: Abstraction via the Marketplace. Instead of manually writing cache restoration and saving steps, the community-maintained setup-node action does the heavy lifting. It automatically checks the lockfile, restores the cache before the run, and saves it at the end of the job.

Expanding the Picture: The Broader CI/CD Ecosystem
While GitHub Actions, Bitbucket Pipelines, and CircleCI dominate the modern hosted-YAML space, the DevOps landscape offers specialized tools depending on where your testing management needs to scale:

The Pioneers: Travis CI popularized the .yml config approach long before GitHub Actions existed and remains a solid choice for open-source projects.
The On-Premise Giants: As my colleague noted, Jenkins offers unmatched plugin control. However, GitLab CI/CD is often preferred by enterprises because it offers a similarly robust self-hosted option but with a native, integrated interface rather than relying on a fragmented plugin ecosystem.
Enterprise Polish: TeamCity (by JetBrains) provides deep IDE integrations and visual pipeline builders. It excels in enterprise environments where complex test reporting and historical flakiness analysis are prioritized over raw YAML scripting.
The Cloud-Native Frontier: If you manage testing infrastructure at a massive scale, traditional servers become a bottleneck. Tekton solves this by turning your Kubernetes cluster into the CI engine, running every testing step as a native K8s pod.
Beyond CI to Continuous Delivery: Passing the test suite is only the beginning. Platforms like Harness specialize in complex deployment orchestration. Once your Gitlab or GitHub pipeline turns green, Harness takes over to manage canary releases, AI-assisted rollbacks, and multi-cloud delivery.

Conclusion
A fast CI pipeline is a feature, not a luxury. When comparing testing management tools, looking purely at syntax is not enough; you must evaluate how they handle the friction of daily development. Bitbucket Pipelines offers unmatched simplicity for caching, CircleCI gives you absolute granular speed control, and GitHub Actions relies on community abstraction.

The best tool is the one that allows your developers to push code, get a green or red test signal within seconds, and move on. Optimize your caches, containerize your dependencies, and never let your automated gatekeeper become a bottleneck.

Demo repository (all three pipelines):
https://github.com/GianfrancoArocutipa/ci-testing-comparative

Applying API Testing Frameworks: Bulletproofing Your REST APIs Against Edge Cases and Bad Actors

FabrizioPerezPeralta — Mon, 06 Jul 2026 05:00:43 +0000

Abstract
When developing a REST API, proving that the system works under ideal conditions (the "happy path") is only a fraction of the job. In the real world, APIs are constantly bombarded with malformed payloads, unauthorized access attempts, and conflicting state changes. This article explores how to use Jest and Supertest to enforce strict security boundaries and robust data validation. Using a real-world vehicle-workshop API as our target, we will dive into "Negative Testing"—writing automated integration tests specifically designed to ensure the API fails gracefully and securely when presented with invalid tokens, bad data, and resource conflicts.

The Illusion of the Happy Path
A test suite that only verifies 200 OK responses provides a false sense of security. An API is essentially a gateway to your database and business logic. If it accepts an incomplete payload or blindly trusts a user's input, it introduces vulnerabilities and corrupts data integrity.

Using the Node.js ecosystem standard—Jest as the test runner and Supertest to execute HTTP assertions directly against the Express app in memory—we can aggressively simulate bad actors and edge cases in milliseconds. Since the server runs in-memory (bypassing the network layer), we can run hundreds of security checks without slowing down the CI pipeline.

Let's look at how to implement the three most critical defensive API tests based on a vehicle management system.

1. Validating Security Boundaries (401 Unauthorized)
Before processing any business logic, an API must verify the caller's identity. Security testing shouldn't be left to manual QA; it must be an automated contract.

In our vehicle API, registering a new vehicle requires an API key. We must test not only the absence of the key but also the presence of an invalid one:

JavaScript
describe('POST /api/vehicles - Security Boundaries', () => {
  const newVehicle = {
    plate: 'ABC-123',
    owner: 'Maria Lopez',
    model: 'Toyota Hilux',
    status: 'in_service'
  };

  test('rejects the request with 401 when x-api-key header is missing', async () => {
    const res = await request(app)
      .post('/api/vehicles')
      .send(newVehicle); // No .set() called

    expect(res.status).toBe(401);
    expect(res.body.error).toMatch(/unauthorized/i);
  });

  test('rejects the request with 401 when the API key is invalid', async () => {
    const res = await request(app)
      .post('/api/vehicles')
      .set('x-api-key', 'SUPER_SECRET_HACKER_KEY')
      .send(newVehicle);

    expect(res.status).toBe(401);
  });
});

2. Strict Payload Validation (400 Bad Request)
Never trust the client. If your API expects a specific data structure, you must verify that missing fields, empty strings, or incorrect data types are immediately rejected.

A robust validation test suite ensures that the API returns a 400 Bad Request and explicitly tells the client what went wrong, preventing malformed data from ever reaching the database layer:

JavaScript
describe('POST /api/vehicles - Payload Validation', () => {
  const validKey = 'YOUR_VALID_API_KEY';

  test('returns 400 when required fields are missing', async () => {
    const incompleteVehicle = {
      owner: 'Jose Quispe'
      // missing 'plate', 'model', and 'status'
    };

    const res = await request(app)
      .post('/api/vehicles')
      .set('x-api-key', validKey)
      .send(incompleteVehicle);

    expect(res.status).toBe(400);
    // Ensure the API lists exactly what is missing
    expect(res.body.errors).toContain('plate is required');
    expect(res.body.errors).toContain('model is required');
  });

  test('returns 400 when sending invalid data types', async () => {
    const res = await request(app)
      .post('/api/vehicles')
      .set('x-api-key', validKey)
      .send({ plate: 12345, owner: true }); // Should be strings

    expect(res.status).toBe(400);
  });
});

3. Handling Resource Conflicts and Idempotency (409 Conflict)
What happens if two clients try to register the exact same vehicle at the exact same time, or if a user accidentally double-clicks a submit button? Your API must protect the uniqueness of its resources.

For our workshop API, the plate acts as a unique identifier. We must ensure that attempting to create a duplicate record results in a 409 Conflict rather than silently overwriting the data or throwing an unhandled 500 Internal Server Error:

JavaScript
describe('POST /api/vehicles - State Conflicts', () => {
  const validKey = 'YOUR_VALID_API_KEY';
  const vehicle = {
    plate: 'XYZ-789',
    owner: 'Carlos Ruiz',
    model: 'Honda Civic',
    status: 'ready'
  };

  test('returns 409 when the vehicle plate is already registered', async () => {
    // 1. Insert the vehicle successfully
    await request(app)
      .post('/api/vehicles')
      .set('x-api-key', validKey)
      .send(vehicle);

    // 2. Attempt to insert the exact same vehicle again
    const duplicateRes = await request(app)
      .post('/api/vehicles')
      .set('x-api-key', validKey)
      .send(vehicle);

    // 3. Assert the conflict is caught and handled safely
    expect(duplicateRes.status).toBe(409);
    expect(duplicateRes.body.error).toMatch(/already registered/i);
  });
});

Conclusion
Building integration tests with Jest and Supertest is about much more than verifying that your endpoints work; it’s about proving that they don't work when they shouldn't. By treating authentication bypasses, validation failures, and data conflicts as core components of your automated testing strategy, you shift security and reliability to the left.

You no longer have to wait for an integration bug in production or a security audit to find out your endpoint accepts garbage data. With in-memory API testing, you can execute these critical defensive checks in less than a second on every single commit.

Demo repository (code + CI workflow):
https://github.com/GianfrancoArocutipa/api-testing-demo.git

Applying SAST to Infrastructure as Code: Unifying Cloud and Container Security with Trivy

FabrizioPerezPeralta — Mon, 06 Jul 2026 04:34:39 +0000

Author: Fabrizio Salvador Elias Perez Peralta

Abstract
As Infrastructure as Code (IaC) evolves, the boundary between cloud provisioning and container configuration blurs. This article explores the application of Static Application Security Testing (SAST) using Trivy, an open-source vulnerability scanner listed in the OWASP tools catalog. While my colleague Gianfranco demonstrated the power of Checkov for AWS (referenced in GianfrancoArocutipa/checkov-iac-demo), this piece expands the scope by scanning both a Terraform deployment and a Docker container configuration in a single pass. The demonstration uncovers critical misconfigurations—including root-level container execution and unencrypted cloud storage—and details how to remediate them. Finally, it showcases how Trivy's SARIF output can be integrated into GitHub Actions, emphasizing the importance of developer experience and automated security gates in modern DevSecOps workflows.

The Evolution of IaC and the Need for SAST
In the modern DevSecOps landscape, a vulnerable system is rarely just about bad PHP or Python code. Often, the breach happens at the infrastructure level. You can write the most secure application in the world, but if the Docker container runs as root and the Terraform-managed S3 bucket holding the backups is public, you are compromised.

SAST tools for IaC analyze configuration files (like .tf, Dockerfile, or kubernetes.yaml) against hundreds of security policies before any infrastructure is actually created. This allows developers to catch misconfigurations right in their IDE or Continuous Integration (CI) pipeline.

Why Trivy?
While Checkov is an outstanding policy-as-code tool, Trivy (by Aqua Security) takes a "comprehensive scanner" approach. It is widely loved in the Linux and Docker communities because a single binary can scan container images, file systems, Git repositories, and IaC configurations (Terraform, CloudFormation, Kubernetes, Dockerfiles) seamlessly. It is fast, stateless, and requires no prerequisites.

The Victim: A Containerized App Managed by Terraform
For this demonstration, we have a small project containing two critical IaC files: a Dockerfile for our application and a main.tf to deploy cloud resources.

1. The Vulnerable Dockerfile:

# Dockerfile
FROM ubuntu:20.04
RUN apt-get update && apt-get install -y curl
COPY myapp /app/
# VULNERABILITY: No USER specified, runs as root by default
CMD ["/app/myapp"]

2. The Vulnerable Terraform (main.tf):

# main.tf
provider "aws" {
  region = "us-east-1"
}

resource "aws_s3_bucket" "app_data" {
  bucket = "company-sensitive-app-data"
  # VULNERABILITY: No encryption at rest configured
}

resource "aws_security_group" "web" {
  # VULNERABILITY: SSH exposed to the world
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

Step 1: Install and Run Trivy
Trivy is incredibly easy to use on Linux. You can install it via an apt package, homebrew, or simply pull the binary. Once installed, we instruct Trivy to scan our entire directory for IaC misconfigurations:

trivy config ./infrastructure
Step 2: Analyzing the Scan Results
In a matter of seconds, Trivy parses both the Dockerfile and the Terraform code. The output instantly highlights the critical flaws:

Plaintext
infrastructure/Dockerfile (dockerfile)
======================================
Tests: 23 (SUCCESSES: 22, FAILURES: 1, EXCEPTIONS: 0)
Failures: 1 (HIGH: 1, CRITICAL: 0)

+---------------------------+------------+-----------------------------------------+
|           TYPE            |  SEVERITY  |                 MESSAGE                 |
+---------------------------+------------+-----------------------------------------+
| DS002                     | HIGH       | Specify at least 1 USER command in      |
|                           |            | Dockerfile with non-root user as        |
|                           |            | arguments                               |
+---------------------------+------------+-----------------------------------------+

infrastructure/main.tf (terraform)
==================================
Tests: 45 (SUCCESSES: 43, FAILURES: 2, EXCEPTIONS: 0)
Failures: 2 (HIGH: 1, CRITICAL: 1)

+---------------------------+------------+-----------------------------------------+
|           TYPE            |  SEVERITY  |                 MESSAGE                 |
+---------------------------+------------+-----------------------------------------+
| AVD-AWS-0088              | HIGH       | S3 Bucket does not have encryption      |
|                           |            | enabled                                 |
+---------------------------+------------+-----------------------------------------+
| AVD-AWS-0107              | CRITICAL   | Security group rule allows ingress      |
|                           |            | from public internet to port 22         |
+---------------------------+------------+-----------------------------------------+

Trivy not only caught the Terraform misconfigurations (unencrypted bucket and open SSH port) but also flagged that our container is violating the principle of least privilege by running as root.

Step 3: Hardening the Code
We remediate the issues by updating our IaC files with secure defaults.

Fixed Dockerfile:

FROM ubuntu:20.04
RUN useradd -m appuser
COPY myapp /app/
USER appuser # Fixed: Running as a non-root user
CMD ["/app/myapp"]
Fixed Terraform:

Terraform
resource "aws_s3_bucket" "app_data" {
  bucket = "company-sensitive-app-data"
}

resource "aws_s3_bucket_server_side_encryption_configuration" "app_data_encryption" {
  bucket = aws_s3_bucket.app_data.id
  rule {
    apply_server_side_encryption_by_default {
      sse_algorithm = "AES256" # Fixed: Encryption at rest enforced
    }
  }
}

resource "aws_security_group" "web" {
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["10.0.0.0/16"] # Fixed: Restricted to internal VPN
  }
}
Running trivy config ./infrastructure again yields a clean report with FAILURES: 0.

Step 4: Automating the Developer Experience (CI/CD)
As a developer who works on building custom vulnerability analyzers (like Anzencore) and IDE extensions, I know that CLI tools are only half the battle. If a security tool isn't integrated into the developer workflow, it won't be used.

By integrating Trivy into GitHub Actions, we can block pull requests that introduce vulnerable infrastructure. Trivy supports outputting to the SARIF (Static Analysis Results Interchange Format) standard, which integrates natively with GitHub Code Scanning.

name: IaC SAST - Trivy Scan
on:
  pull_request:
    branches: [ main ]

jobs:
  trivy-scan:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Run Trivy vulnerability scanner in IaC mode
        uses: aquasecurity/trivy-action@master
        with:
          scan-type: 'config'
          hide-progress: false
          format: 'sarif'
          output: 'trivy-results.sarif'
          exit-code: '1'

      - name: Upload Trivy scan results to GitHub Security tab
        uses: github/codeql-action/upload-sarif@v3
        if: always()
        with:
          sarif_file: 'trivy-results.sarif'

Conclusion
By treating our containers and cloud deployments as code, SAST tools like Trivy allow us to push security to the very beginning of the software development lifecycle. Whether we are writing Terraform to spin up AWS resources or crafting Dockerfiles, scanning these text files for known architectural vulnerabilities prevents costly breaches before they happen. Integrating these tools through automated CI/CD gates ensures that security becomes an enabler of quality, rather than a blocker of speed.

Demo repository (code + CI workflow): https://github.com/GianfrancoArocutipa/checkov-iac-demo(#)

Shifting Mobile Security Left: Applying SAST to Android Apps with MobSF

FabrizioPerezPeralta — Mon, 06 Jul 2026 04:17:30 +0000

TL;DR — I took an intentionally vulnerable Android application, ran the static analysis engine of MobSF (Mobile Security Framework) via a local Docker container, and immediately identified critical flaws like hardcoded API keys and insecure local data storage. In mobile development, catching these issues at the source code level is vital before the APK is compiled, signed, and distributed.

The Challenge of Mobile SAST
Static Application Security Testing (SAST) is widely discussed in web development, but mobile ecosystems bring their own unique attack vectors. In Android, an attacker isn't just sending malicious payloads to a server; they can decompile the APK, inspect the manifest, and extract hardcoded secrets directly from the binary.

When architecting mobile vulnerability analyzers—like Anzencore, for example—the primary objective is to inspect the raw code and configuration files before the build process even begins. We need to identify when developers fail to meet critical non-functional requirements, such as secure data synchronization and encrypted local storage.

Why MobSF?
The OWASP Source Code Analysis Tools catalog is extensive, but many mainstream commercial tools are heavily web-focused. I chose MobSF because it is an open-source, specialized framework designed explicitly for mobile apps (Android/iOS/Windows). While it can perform dynamic analysis, its static analysis engine is incredibly powerful for parsing AndroidManifest.xml files, reverse-engineering Dalvik bytecode, and scanning Java/Kotlin source code for insecure implementations.

Step 1: Spinning up the Analyzer
Because we want to keep our host machine clean and avoid dependency hell, we will deploy MobSF using Docker. It takes just two commands in a Linux environment to get the local server running:

# Pull the latest MobSF image
docker pull opensecurity/mobile-security-framework-mobsf:latest

# Run the container on port 8000
docker run -it -p 8000:8000 opensecurity/mobile-security-framework-mobsf:latest
Once running, the web interface is accessible at localhost:8000, ready to ingest an APK or a ZIP of the source code.

The Victim: A Vulnerable Android App
For this test, I uploaded an open-source vulnerable Android application (similar to InsecureBankv2). Instead of executing the app, MobSF decompiles it and runs its SAST ruleset against the extracted source.

Within 60 seconds, the dashboard populated with critical findings. Here are the two most dangerous vulnerabilities caught by the static scan:

1. Hardcoded Secrets (CWE-798)
MobSF flagged the res/values/strings.xml file. A developer left a production AWS access key directly in the code:

<!-- Flagged by MobSF: Hardcoded sensitive information -->
<string name="aws_access_key">AKIAIOSFODNN7EXAMPLE</string>
Why it matters: Anyone who downloads the app from the Play Store can use a tool like Apktool to extract this string in seconds.

2. Insecure Data Storage (CWE-312)
The analyzer traced a data flow in the Kotlin backend where user session tokens were being saved using SharedPreferences without the EncryptedSharedPreferences wrapper.

// Flagged by MobSF: Insecure SharedPreferences implementation
val sharedPref = activity?.getPreferences(Context.MODE_PRIVATE)
with (sharedPref.edit()) {
    putString("session_token", userToken) // Tainted data sink
    apply()
}

Why it matters: If the device is rooted, MODE_PRIVATE does not protect the XML file from being read by other malicious applications on the device. Secure storage is a non-functional requirement that must be enforced at the architectural level.

The Next Evolution: Bringing SAST to the IDE
While running a Dockerized SAST tool is great for CI/CD pipelines, the feedback loop can be tightened even further.

The future of SAST isn't just in dashboards; it’s in the developer's immediate workspace. The ultimate goal is to transform tools like these into VS Code extensions or AI-assisted IDE plugins. By bringing the vulnerability analyzer directly into the code editor as a language server "skill", developers receive inline warnings the exact moment they type a hardcoded secret or implement an insecure storage method.

Conclusion
Mobile applications require specialized security tooling. By leveraging MobSF’s static analysis capabilities, we found critical data storage and hardcoded secret vulnerabilities without ever launching an emulator. Automating this process ensures that fundamental security requirements are met before a single line of code reaches production.

Demo repository (code + CI workflow): https://github.com/GianfrancoArocutipa/psalm-sast-demo(#)