DEV Community: DIEGO FABRIZIO ANDIA NAVARRO

Applying a SAST Tool to Infrastructure as Code: Scanning a Terraform Stack with Checkov

DIEGO FABRIZIO ANDIA NAVARRO — Tue, 30 Jun 2026 19:10:58 +0000

Abstract

Application code isn't the only place a SAST tool belongs — infrastructure definitions are source code too, and misconfigurations written into a Terraform file ship to production exactly as reliably as a bug in application logic does. This article applies Checkov, an open-source static analysis tool for Infrastructure as Code, to a Terraform stack that provisions storage, networking, a database, and IAM permissions for an order service. The unmodified stack produced 36 failed checks against 14 passed. After remediating every finding that represented an actual exploitable risk, the same stack passed 57 checks with 6 remaining — and those 6 turned out to be business decisions (replication, lifecycle policies) rather than vulnerabilities, which is itself the more useful finding: not every flagged item deserves the same response.

Why IaC needs its own static analysis, separate from application SAST

A SAST tool for application code looks for dangerous function calls and data flows. A SAST tool for IaC looks for a different category entirely: resource configurations that violate a known-safe default. An aws_s3_bucket with no aws_s3_bucket_public_access_block isn't a code bug in the traditional sense — the Terraform is syntactically perfect and will apply cleanly. The risk is purely in what gets provisioned. That's precisely the gap Checkov, Terrascan, and similar tools are built to close: they evaluate the intended infrastructure state, not the code that produces it.

The real-world example: a Terraform stack for an order service

A small but realistic stack: an S3 bucket for order exports, a security group, an RDS database, an IAM policy, an EBS volume, and a CloudWatch log group.

# terraform-vulnerable/main.tf
resource "aws_s3_bucket" "order_exports" {
  bucket = "store-order-exports"
  acl    = "public-read"
}

resource "aws_security_group" "app_sg" {
  ingress {
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

resource "aws_db_instance" "orders_db" {
  password             = "Sup3rSecret!2024"
  publicly_accessible  = true
  storage_encrypted    = false
}

resource "aws_iam_policy" "app_policy" {
  policy = jsonencode({
    Statement = [{ Effect = "Allow", Action = "*", Resource = "*" }]
  })
}

Nothing here fails terraform validate — it's all valid HCL that will provision successfully. That's exactly why this category of risk needs a dedicated scanner instead of relying on the provider to reject something dangerous.

Running Checkov against it

pip install checkov
checkov -d terraform-vulnerable --compact

Real, unedited output (excerpt):

Check: CKV_AWS_20: "S3 Bucket has an ACL defined which allows public READ access."
    FAILED for resource: aws_s3_bucket.order_exports

Check: CKV_AWS_24: "Ensure no security groups allow ingress from 0.0.0.0:0 to port 22"
    FAILED for resource: aws_security_group.app_sg

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

Check: CKV_AWS_17: "Ensure all data stored in RDS is not publicly accessible"
    FAILED for resource: aws_db_instance.orders_db

Check: CKV_AWS_62: "Ensure IAM policies that allow full "*-*" administrative privileges are not created"
    FAILED for resource: aws_iam_policy.app_policy

Check: CKV_AWS_3: "Ensure all data stored in the EBS is securely encrypted"
    FAILED for resource: aws_ebs_volume.app_data

Passed checks: 14, Failed checks: 36, Skipped checks: 0

Every failed check carries a stable ID (CKV_AWS_*), which is what makes a finding something a team can track, suppress with a documented reason, or treat as a release blocker — instead of a one-off comment in a pull request.

Fixing what's actually a risk

Resource	Finding	Fix
S3 bucket	Public-read ACL, no versioning, no encryption	Remove the ACL, add `aws_s3_bucket_public_access_block`, `aws_s3_bucket_versioning`, `aws_s3_bucket_server_side_encryption_configuration`
Security group	SSH and Postgres open to `0.0.0.0/0`	Scope `cidr_blocks` to the office VPN and the app subnet specifically
RDS instance	Public access, unencrypted storage, hardcoded password	`publicly_accessible = false`, `storage_encrypted = true`, `manage_master_user_password = true` (AWS-managed via Secrets Manager)
IAM policy	`Action: ""` on `Resource: ""`	Scope to the two S3 actions the service actually needs, on the specific bucket ARN
EBS volume	Unencrypted	`encrypted = true` with a customer-managed KMS key
CloudWatch log group	No retention period	`retention_in_days = 365`

# terraform-fixed/main.tf
resource "aws_security_group" "app_sg" {
  ingress {
    description = "SSH from the office VPN only"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["203.0.113.0/24"]
  }
}

resource "aws_db_instance" "orders_db" {
  manage_master_user_password = true
  publicly_accessible         = false
  storage_encrypted           = true
  deletion_protection         = true
}

resource "aws_iam_policy" "app_policy" {
  policy = jsonencode({
    Statement = [{
      Effect   = "Allow"
      Action   = ["s3:GetObject", "s3:PutObject"]
      Resource = "${aws_s3_bucket.order_exports.arn}/*"
    }]
  })
}

Re-scanning: from 36 failures to 6

$ checkov -d terraform-fixed --compact
Passed checks: 57, Failed checks: 6, Skipped checks: 0

The remaining 6 are worth looking at individually, because none of them are the same category of risk as the original 36:

CKV2_AWS_62  Ensure S3 buckets should have event notifications enabled
CKV_AWS_144  Ensure that S3 bucket has cross-region replication enabled
CKV2_AWS_61  Ensure that an S3 bucket has a lifecycle configuration
CKV2_AWS_64  Ensure KMS key Policy is defined
CKV2_AWS_30  Ensure Postgres RDS has Query Logging enabled
CKV_AWS_354  Ensure RDS Performance Insights are encrypted using KMS CMKs

Cross-region replication and lifecycle rules are cost and disaster-recovery decisions, not vulnerabilities — applying them blindly to satisfy a scanner would add infrastructure cost without addressing any actual exposure. Query logging and Performance Insights encryption are reasonable hardening that a team might genuinely choose to defer. This is the point a checklist mentality misses: the job of a SAST tool is to surface every deviation from a safe default, and the job of the engineer is still to decide which deviations matter for this specific system.

Wiring it into CI

# .github/workflows/checkov.yml
name: IaC SAST scan (Checkov)

on:
  push:
    branches: ["main"]
  pull_request:

jobs:
  checkov:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install checkov
      - run: checkov -d terraform-fixed --compact --soft-fail-on LOW

Running this on every terraform plan means a public S3 bucket or an open security group never reaches apply without someone explicitly seeing — and accepting — the finding first.

Conclusion

The first scan caught real, exploitable misconfiguration: a publicly readable bucket, an internet-facing database with a hardcoded password, an IAM policy with unrestricted * access. Those aren't edge cases — they're exactly the kind of thing that ends up in a breach disclosure. The second scan is the more instructive result: not every one of the remaining 6 findings deserved a fix, and treating a SAST tool's output as a literal to-do list rather than a prioritized list of deviations to evaluate is how teams either burn time hardening low-risk defaults or, worse, learn to ignore the tool altogether. Static analysis for infrastructure is most useful exactly where this example landed — as the thing that catches the dangerous default, while leaving the judgment calls to the team that owns the system.

Applying a SAST Tool to a Real Application: Finding and Fixing 10 Vulnerabilities with Bandit

DIEGO FABRIZIO ANDIA NAVARRO — Tue, 30 Jun 2026 19:04:58 +0000

Abstract

Static Application Security Testing (SAST) tools read source code without running it, looking for patterns that are known to be dangerous: string-built SQL queries, hardcoded secrets, unsafe deserialization, and similar mistakes that are easy to write and easy to miss in review. This article applies Bandit — a SAST tool for Python listed in OWASP's Source Code Analysis Tools directory — to a small order-lookup service for an online store. The vulnerable version was scanned first, producing 10 real findings across three severity levels. Each finding was then fixed individually, and the fixed file was scanned again, surfacing one additional issue Bandit caught that had been missed during manual remediation, before reaching a fully clean scan. The goal isn't to demonstrate Bandit's feature list — it's to show what a SAST tool actually catches in a piece of code that looks unremarkable at a glance.

Why static analysis catches what code review often doesn't

A SAST tool doesn't understand what your application does — it doesn't know what a "discount" or an "order" means. What it knows is a large catalog of dangerous patterns: eval() on user input, subprocess calls with shell=True, MD5 used where a password hash is expected, pickle.loads() on data that could come from outside the process. A human reviewer skimming a pull request can miss these because they're often one line buried in otherwise-correct logic. A SAST tool reads every line, every time, without getting tired.

The real-world example: an order service with 7 intentional mistakes

The starting point is a small Flask service with the kind of issues that show up in real codebases — not contrived examples, but the exact shape of mistakes that get written under deadline pressure:

# order_service.py
DB_PASSWORD = "Sup3rSecret!2024"

def find_order_by_customer(customer_name):
    conn = get_connection()
    cursor = conn.cursor()
    query = "SELECT * FROM orders WHERE customer_name = '%s'" % customer_name
    cursor.execute(query)
    return cursor.fetchall()

def calculate_discount_expression(expression):
    return eval(expression)

def export_orders_to_csv(filename):
    subprocess.call("cp orders.db /tmp/" + filename, shell=True)

def hash_password(password):
    return hashlib.md5(password.encode()).hexdigest()

def load_cached_cart(serialized_cart):
    return pickle.loads(serialized_cart)

Running Bandit against it

pip install bandit
bandit order_service.py

Real, unedited output:

Run metrics:
    Total issues (by severity):
        Low: 3
        Medium: 4
        High: 3

>> Issue: [B608:hardcoded_sql_expressions] Possible SQL injection vector through string-based query construction.
   Severity: Medium   Confidence: Low   CWE: CWE-89
   Location: ./order_service.py:31

>> Issue: [B307:blacklist] Use of possibly insecure function - consider using safer ast.literal_eval.
   Severity: Medium   Confidence: High   CWE: CWE-78
   Location: ./order_service.py:39

>> Issue: [B602:subprocess_popen_with_shell_equals_true] subprocess call with shell=True identified, security issue.
   Severity: High   Confidence: High   CWE: CWE-78
   Location: ./order_service.py:44

>> Issue: [B324:hashlib] Use of weak MD5 hash for security. Consider usedforsecurity=False
   Severity: High   Confidence: High   CWE: CWE-327
   Location: ./order_service.py:49

>> Issue: [B301:blacklist] Pickle and modules that wrap it can be unsafe when used to deserialize untrusted data.
   Severity: Medium   Confidence: High   CWE: CWE-502
   Location: ./order_service.py:54

>> Issue: [B201:flask_debug_true] A Flask app appears to be run with debug=True, which exposes the Werkzeug
   debugger and allows the execution of arbitrary code.
   Severity: High   Confidence: Medium   CWE: CWE-94
   Location: ./order_service.py:71

Ten findings total — three Low, four Medium, three High. Note that Bandit doesn't just flag the call site; it attaches a CWE (Common Weakness Enumeration) ID to each one, which is what lets a finding map directly to a recognized vulnerability category instead of being just an opinion.

Fixing each finding

Finding	Fix
Hardcoded password & API key	Read from environment variables (`os.environ.get(...)`)
SQL injection via `%` formatting	Parameterized query: `cursor.execute(query, (customer_name,))`
`eval()` on user input	`ast.literal_eval()`, which only evaluates literals, never arbitrary code
`subprocess` with `shell=True`	`shutil.copy()` with no shell, plus `os.path.basename()` to strip path traversal
MD5 for password hashing	`bcrypt.hashpw()`
`pickle.loads()` on untrusted data	`json.loads()` instead — JSON can't execute code during deserialization
Flask `debug=True` + bind to `0.0.0.0`	`debug` driven by an explicit environment flag, bind to `127.0.0.1` by default

# order_service_fixed.py
def find_order_by_customer(customer_name):
    conn = get_connection()
    cursor = conn.cursor()
    query = "SELECT * FROM orders WHERE customer_name = ?"
    cursor.execute(query, (customer_name,))
    return cursor.fetchall()

def calculate_discount_expression(expression):
    try:
        return ast.literal_eval(expression)
    except (ValueError, SyntaxError):
        raise ValueError("Invalid expression")

def hash_password(password):
    return bcrypt.hashpw(password.encode(), bcrypt.gensalt())

The re-scan caught something the manual fix missed

Running Bandit again after the fixes:

$ bandit order_service_fixed.py

>> Issue: [B108:hardcoded_tmp_directory] Probable insecure usage of temp file/directory.
   Severity: Medium   Confidence: Medium   CWE: CWE-377
   Location: ./order_service_fixed.py:47

The shell-injection fix had replaced subprocess with shutil.copy(), but it still wrote to a hardcoded /tmp path — a pattern that's vulnerable to race conditions on shared systems. This is the actual value of a SAST tool in a pipeline: it doesn't just catch the obvious first pass, it catches what a human fixing five things in a row reasonably overlooks on the sixth. Swapping in tempfile.gettempdir() resolved it:

$ bandit order_service_fixed.py

Test results:
    No issues identified.

Run metrics:
    Total issues (by severity):
        Low: 0
        Medium: 0
        High: 0

Wiring it into CI

The same command that ran locally becomes a merge gate:

# .github/workflows/sast.yml
name: SAST scan (Bandit)

on:
  push:
    branches: ["main"]
  pull_request:

jobs:
  bandit:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"
      - run: pip install bandit
      - run: bandit -r . -x ./tests -ll

The -ll flag tells Bandit to fail the build only on Medium severity and above, which is a reasonable starting threshold — failing on every Low finding tends to train a team to ignore the tool's output entirely.

What a SAST tool is and isn't good for

Bandit found real, valid issues here — but it's worth being precise about its limits. It works on syntax and known-dangerous-call patterns, so it won't catch a logic flaw like an authorization check that's present but wrong, and it can produce false positives (notice the SQL-injection finding above was flagged at "Confidence: Low" — the tool is also telling you how sure it is). SAST is one layer: it belongs alongside code review, dependency scanning, and — for anything handling real user data — a second pair of human eyes on anything it flags as High severity.

Conclusion

Every one of the 10 findings here came from code that compiles, runs, and would pass a casual review — that's exactly the kind of mistake static analysis exists to catch. The more interesting result wasn't the first scan, it was the second one: fixing six vulnerabilities by hand still left a seventh, smaller one in the remediation itself. That's the actual argument for running a SAST tool in CI rather than as a one-time audit — it checks the fix the same way it checked the original bug.

Applying API Testing Frameworks: A Loyalty Discount Endpoint Tested with Supertest, pytest, Postman/Newman, and REST Assured

DIEGO FABRIZIO ANDIA NAVARRO — Tue, 30 Jun 2026 18:53:02 +0000

Abstract

API testing frameworks are often picked by team habit rather than by what the tool actually verifies. This article applies four widely used frameworks — Supertest + Jest (Node), pytest + requests (Python), Postman/Newman, and REST Assured (Java) — against the same real endpoint: a loyalty-discount calculator exposed over HTTP. Each suite was written against the live API and actually executed; the Supertest, pytest, and Newman runs below show real, unedited output, not illustrative snippets. The goal isn't to crown a winner — it's to show what changes (syntax, assertion style, how the server is reached) and what doesn't (the contract being verified) when you swap the framework underneath the same API.

Why API testing is a different layer than unit testing

A unit test calls a function directly, in-process. An API test goes through the actual HTTP boundary: it serializes a request, sends it over a socket (or an in-memory equivalent), and checks the status code, headers, and response body the same way a real client would. That extra layer is exactly the point — it catches bugs a unit test can't see, like a route returning the wrong status code, a missing Content-Type header, or a field silently dropped during JSON serialization.

The real-world example: a loyalty discount API

The same business rules from a previous article, now exposed as an endpoint instead of a bare function:

POST /api/discount with { subtotal, tier, ordersCount }.
new tier: 0% off. silver (5+ orders): 10% off. gold (20+ orders): 20% off.
Discount capped at $50.
Invalid input returns 400; a tier without enough orders returns 422.

// src/app.js
app.post("/api/discount", (req, res) => {
  try {
    const { subtotal, tier, ordersCount } = req.body;
    const result = calculateDiscount(subtotal, tier, ordersCount);
    res.status(200).json(result);
  } catch (err) {
    res.status(err.status || 500).json({ error: err.message });
  }
});

1. Supertest + Jest (Node)

Supertest wraps the Express app directly — no server process needs to be running, it talks to the app in memory.

// test-node/discount.test.js
const request = require("supertest");
const { createApp } = require("../src/app");
const app = createApp();

test("silver members get 10% off once they have 5+ orders", async () => {
  const res = await request(app)
    .post("/api/discount")
    .send({ subtotal: 80, tier: "silver", ordersCount: 5 });

  expect(res.status).toBe(200);
  expect(res.body.discount).toBe(8);
});

test("discount is capped at $50 even for large orders", async () => {
  const res = await request(app)
    .post("/api/discount")
    .send({ subtotal: 1000, tier: "gold", ordersCount: 25 });

  expect(res.status).toBe(200);
  expect(res.body.discount).toBe(50);
});

Real, unedited run:

$ npx jest --runInBand
PASS test-node/discount.test.js
  POST /api/discount
    ✓ new members receive no discount (29 ms)
    ✓ silver members get 10% off once they have 5+ orders (4 ms)
    ✓ discount is capped at $50 even for large orders (3 ms)
    ✓ rejects a tier that doesn't have enough orders yet (3 ms)
    ✓ rejects a negative subtotal with 400 (4 ms)
  GET /api/health
    ✓ returns ok status (7 ms)

Tests:       6 passed, 6 total

Best fit: teams already writing the API in Node/Express who want fast, in-process tests with no network round trip.

2. pytest + requests (Python)

Unlike Supertest, this hits a real running server over the network — closer to how an external client or a QA engineer would test it.

# test-python/test_discount_api.py
import requests

BASE_URL = "http://127.0.0.1:3000"

def test_silver_member_gets_ten_percent():
    res = requests.post(f"{BASE_URL}/api/discount", json={
        "subtotal": 80, "tier": "silver", "ordersCount": 5
    })
    assert res.status_code == 200
    assert res.json()["discount"] == 8

def test_discount_capped_at_fifty():
    res = requests.post(f"{BASE_URL}/api/discount", json={
        "subtotal": 1000, "tier": "gold", "ordersCount": 25
    })
    assert res.status_code == 200
    assert res.json()["discount"] == 50

Real, unedited run against the live server:

$ python3 -m pytest test-python/ -v
test_discount_api.py::test_new_member_no_discount PASSED
test_discount_api.py::test_silver_member_gets_ten_percent PASSED
test_discount_api.py::test_discount_capped_at_fifty PASSED
test_discount_api.py::test_rejects_tier_without_enough_orders PASSED
test_discount_api.py::test_rejects_negative_subtotal PASSED
test_discount_api.py::test_health_check PASSED

============================== 6 passed in 0.12s ===============================

Best fit: QA-focused teams, polyglot organizations where the API consumer isn't a Node app, or anyone who wants tests fully decoupled from the implementation language.

3. Postman/Newman

Postman collections are built visually, but they export to plain JSON and run headlessly with Newman — useful for the same suite to live both as a manual exploration tool and as a CI check.

{
  "name": "Discount capped at $50",
  "request": {
    "method": "POST",
    "url": { "raw": "{{baseUrl}}/api/discount" },
    "body": { "raw": "{\"subtotal\": 1000, \"tier\": \"gold\", \"ordersCount\": 25}" }
  },
  "event": [{
    "listen": "test",
    "script": {
      "exec": [
        "pm.test('Discount is capped at 50', function () {",
        "  pm.expect(pm.response.json().discount).to.eql(50);",
        "});"
      ]
    }
  }]
}

Real, unedited run:

$ npx newman run postman/loyalty-discount.postman_collection.json

→ Silver member gets 10% off
  POST http://127.0.0.1:3000/api/discount [200 OK, 306B, 42ms]
  ✓  Status code is 200
  ✓  Discount is 8

→ Discount capped at $50
  POST http://127.0.0.1:3000/api/discount [200 OK, 309B, 4ms]
  ✓  Status code is 200
  ✓  Discount is capped at 50

┌─────────────────────────┬──────────────────┬──────────────────┐
│                         │         executed │           failed │
├─────────────────────────┼──────────────────┼──────────────────┤
│              assertions │                6 │                0 │
└─────────────────────────┴──────────────────┴──────────────────┘

Best fit: teams where non-developers (QA, product) need to inspect and re-run requests visually, with the same collection reused headlessly in CI.

4. REST Assured (Java)

REST Assured brings a fluent, BDD-style syntax (given → when → then) to JVM-based test suites — common when the API consumer or the broader system is already Java/Spring.

// DiscountApiTest.java
@Test
void discountIsCappedAtFifty() {
    given()
        .contentType("application/json")
        .body("{\"subtotal\": 1000, \"tier\": \"gold\", \"ordersCount\": 25}")
    .when()
        .post("/api/discount")
    .then()
        .statusCode(200)
        .body("discount", equalTo(50));
}

This one is included as a reference implementation rather than an executed run in this article — but the assertions are functionally identical to the other three, down to the same boundary case.

Best fit: Java/Spring shops that want API tests to live in the same build (Maven/Gradle) and reporting pipeline as the rest of their JVM test suite.

Comparison

Criterion	Supertest+Jest	pytest+requests	Postman/Newman	REST Assured
Language	JavaScript	Python	JSON (+ JS scripts)	Java
Talks to	App in memory	Live server over HTTP	Live server over HTTP	Live server over HTTP
Best for	Node-native test suites	Cross-language / QA teams	Visual exploration + CI reuse	JVM/Spring shops
Assertion style	`expect(...).toBe(...)`	`assert ... == ...`	`pm.expect(...).to.eql(...)`	`given/when/then` fluent chain
Non-dev friendly	No	Somewhat	Yes (GUI)	No

What actually decides the right framework

Does the test need to reach a real server, or is in-process enough? Supertest skips the network; the other three don't.
Who else needs to read or run these tests? A QA engineer without a dev environment benefits from Postman's GUI far more than from a Jest file.
What language does the rest of the system already use? Matching the API's own stack (Node → Jest, Java → REST Assured) usually means fewer moving parts in CI.
Does the suite need to run unattended in CI, exploratory by hand, or both? Newman covers both with one file; the others are CI-first by default.

Conclusion

All four frameworks verified the exact same contract — same status codes, same discount values, same boundary at $100 and $50. The real decision isn't which one is "best" in the abstract, it's which one matches who's going to read the test a year from now: a Node developer reaches for Supertest, a QA engineer reaches for Postman, and a polyglot test team reaches for pytest or REST Assured depending on the rest of their stack. The contract is the constant; the framework is just how you ask the question.

Choosing a Testing Orchestration Tool: A Loyalty-Discount Module Tested Across GitHub Actions, GitLab CI/CD, Jenkins, and CircleCI

DIEGO FABRIZIO ANDIA NAVARRO — Tue, 30 Jun 2026 18:07:07 +0000

Abstract

Picking a CI tool is often treated as a branding decision, when it should be an engineering one. This article compares GitHub Actions, GitLab CI/CD, Jenkins, and CircleCI as orchestrators for an automated test suite, using a small but realistic loyalty-discount calculator from a subscription e-commerce app as the shared example. The module and its eight tests were written and executed locally first — reaching 100% line, branch, and function coverage — before being wrapped in four equivalent pipeline definitions. The comparison looks at configuration shape, execution model, reuse mechanisms, and operational cost rather than marketing claims. The conclusion is unsurprising but easy to forget under tool-shopping pressure: the orchestration layer should stay thin and replaceable, while the actual safety net — the test suite — should stay portable across whichever platform sits on top of it.

Why "testing management" really means "test orchestration"

None of these four platforms write assertions or decide what "correct" behavior means. What they do is consistently answer one question for every change to a repository: did the existing checks still pass, and can everyone on the team see the answer without running anything locally? That single guarantee is what turns a test suite from a developer's personal habit into a team-wide quality gate.

The real-world example: a loyalty discount calculator

Picture a coffee-subscription app with three loyalty tiers:

New members get no discount.
Silver members (5+ previous orders) get 10% off.
Gold members (20+ previous orders) get 20% off.
The discount is capped at $50 regardless of order size.
Negative subtotals, unknown tiers, or an invalid order count must be rejected.

// loyaltyDiscount.js
const TIER_RULES = {
  new: { minOrders: 0, rate: 0 },
  silver: { minOrders: 5, rate: 0.10 },
  gold: { minOrders: 20, rate: 0.20 },
};

const MAX_DISCOUNT_VALUE = 50;

function calculateLoyaltyDiscount(subtotal, tier, ordersCount) {
  if (!Number.isFinite(subtotal) || subtotal < 0) {
    throw new TypeError("Subtotal must be a non-negative number");
  }
  if (!Object.hasOwn(TIER_RULES, tier)) {
    throw new RangeError("Tier must be one of: new, silver, gold");
  }
  if (!Number.isInteger(ordersCount) || ordersCount < 0) {
    throw new TypeError("ordersCount must be a non-negative integer");
  }

  const rule = TIER_RULES[tier];
  if (ordersCount < rule.minOrders) {
    throw new RangeError(
      `${ordersCount} previous orders is not enough for the "${tier}" tier`
    );
  }

  return Math.min(subtotal * rule.rate, MAX_DISCOUNT_VALUE);
}

module.exports = { calculateLoyaltyDiscount, MAX_DISCOUNT_VALUE };

The risk here isn't exotic — it's the same kind of off-by-one boundary bug that quietly costs real money: a customer with exactly 5 orders should already be Silver, and a $1,000 Gold order should still cap out at a $50 discount, not $200.

One of the eight tests checks that cap directly:

test("discount is capped at $50 even for large orders", () => {
  assert.equal(calculateLoyaltyDiscount(1000, "gold", 25), MAX_DISCOUNT_VALUE);
});

Running the suite locally with Node's built-in test runner gives an honest, unedited result:

$ npm test
ok 1 - new members receive no discount
ok 2 - silver members get 10% off once they have 5+ orders
ok 3 - gold members get 20% off once they have 20+ orders
ok 4 - discount is capped at $50 even for large orders
ok 5 - rejects a tier that doesn't have enough orders yet
ok 6 - rejects a negative subtotal
ok 7 - rejects an unknown tier
ok 8 - rejects a negative or non-integer ordersCount
# tests 8
# pass 8
# fail 0

And the coverage run confirms the business logic is fully exercised, not just superficially tested:

$ npm run test:coverage
file                | line %  | branch % | funcs %
loyaltyDiscount.js  | 100.00  | 100.00   | 100.00
all files           | 100.00  | 100.00   | 100.00

The complete project — module, tests, and all four pipeline files below — is packaged and ready to push as-is to a public GitHub or GitLab repository: [link to your repo here]

GitHub Actions

# .github/workflows/test.yml
name: Automated tests

on:
  push:
    branches: ["main"]
  pull_request:

permissions:
  contents: read

jobs:
  test:
    runs-on: ubuntu-latest
    strategy:
      matrix:
        node-version: [20, 22]

    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: ${{ matrix.node-version }}
      - run: npm run test:coverage

The matrix runs the same eight tests on two Node.js versions with no extra code. Hosted runners mean nobody on the team maintains a build server, and the pull_request trigger surfaces failures before a merge, not after.

GitLab CI/CD

# .gitlab-ci.yml
stages:
  - test

test-node:
  stage: test
  image: node:22
  script:
    - npm run test:coverage

Five lines is enough because the official Node image already has everything the suite needs. The advantage shows up once the project grows: stages, artifacts, environments, and security scanning all live in the same file and the same platform as the rest of the DevOps lifecycle.

Jenkins

// Jenkinsfile
pipeline {
  agent {
    docker { image 'node:22' }
  }
  stages {
    stage('Test') {
      steps {
        sh 'npm run test:coverage'
      }
    }
  }
}

Functionally identical output to the two pipelines above, but the agent runs wherever the team points it — a private network, specialized hardware, an on-prem cluster. That freedom is the entire reason Jenkins still exists in 2026: it doesn't assume your infrastructure looks like anyone else's.

CircleCI

# .circleci/config.yml
version: 2.1

orbs:
  node: circleci/node@5.1.0

jobs:
  test:
    docker:
      - image: cimg/node:22.0
    steps:
      - checkout
      - node/install-packages:
          pkg-manager: npm
      - run:
          name: Run tests with coverage
          command: npm run test:coverage

workflows:
  test-and-build:
    jobs:
      - test

The node orb hides the boilerplate of caching node_modules, which is normally hand-rolled in the other three tools. CircleCI's strength is exactly this: a CI-first product, unattached to any single source-code host.

Comparison

Criterion	GitHub Actions	GitLab CI/CD	Jenkins	CircleCI
Config file	`.github/workflows/*.yml`	`.gitlab-ci.yml`	`Jenkinsfile`	`.circleci/config.yml`
Best fit	Repos already on GitHub	Repos already on GitLab	Custom/self-managed infra	Teams wanting dedicated cloud CI
Hosted runners	Yes	Yes	Uncommon by default	Yes
Reuse model	Marketplace actions	Includes/components	Plugins/shared libraries	Orbs
Setup effort	Low	Low	Medium–high	Low–medium
Who maintains the runner	GitHub	GitLab	Your team	CircleCI

Bitbucket Pipelines, TeamCity, Travis CI, Tekton, and Harness solve the same orchestration problem for different ecosystems — Bitbucket-hosted code, on-prem enterprise servers, Kubernetes-native pipelines, and delivery governance, respectively. None of them changes what's actually being tested.

What actually decides the right tool

Where does the code already live? Native integration removes a layer of permissions and context-switching.
Who owns the runners — a vendor, or your own team? Self-hosting isn't free just because the software is.
How fast is the feedback loop, including queue time and caching?
Can the pipeline reproduce the constraints of production (containers, private networks, compliance)?
Is the test command itself portable? npm run test:coverage works identically in all four pipelines above — that's not an accident, it's the design goal.

Conclusion

For this module, GitHub Actions is the lowest-friction choice simply because the repository already lives on GitHub — not because it is objectively "better" than the alternatives. The real takeaway is structural: keep business logic tests behind one portable command, and treat the CI configuration as a thin, swappable layer on top of it. A team that does this can move from GitHub Actions to GitLab CI/CD, Jenkins, or CircleCI in an afternoon, because the only thing that ever changes is who presses "run."