Forem: Hashira Belén Vargas Candia

Applying Fortify Static Code Analyzer to a Node.js Application: A Practical Guide

Hashira Belén Vargas Candia — Sat, 06 Dec 2025 04:34:32 +0000

Article by: Hashira Belén Vargas Candia
Systems Engineering Student – Application Security Focus

Introduction to SAST Tools

Static Application Security Testing (SAST) tools analyze source code to identify security vulnerabilities before the application is deployed. While tools like SonarQube, Snyk, and Semgrep are popular, this article explores Micro Focus Fortify Static Code Analyzer (SCA) – an enterprise-grade SAST solution for comprehensive security analysis.

Why Fortify SCA?

Fortify SCA offers:
Multi-language support (Java, .NET, C++, Python, JavaScript, etc.)
Deep code analysis with data flow and control flow tracking
Comprehensive vulnerability database (OWASP Top 10, CWE, etc.)
Integration capabilities with CI/CD pipelines
Detailed remediation guidance

Setting Up Fortify SCA for a Node.js Application

Prerequisites

Micro Focus Fortify SCA installation
Node.js project with source code
Fortify Plugin for your IDE (optional)

Step 1: Installation & Setup

# Download Fortify SCA from official Micro Focus portal
# Install with default settings
# Verify installation
fortify version

Step 2: Configure Scan Settings

Create a fortify-sca.properties file:

# Scan configuration for Node.js application
com.fortify.sca.Phase0HigherOrder.Languages=javascript
com.fortify.sca.EnableHTML5Scan=true
com.fortify.sca.NPM.EnableDependencyScanning=true
com.fortify.sca.Yarn.EnableDependencyScanning=true

Step 3: Running the Scan

# Navigate to your Node.js project directory
cd /path/to/your/nodejs-app

# Run sourceanalyzer to translate source code
sourceanalyzer -b myNodeAppBuild -clean
sourceanalyzer -b myNodeAppBuild -source 1.8 **/*.js **/*.ts **/*.jsx **/*.tsx

# Scan for vulnerabilities
fortifyclient start scan -b myNodeAppBuild

Real-World Example: Vulnerable Node.js Code

Before SAST Analysis

// app.js - Vulnerable code examples

// 1. SQL Injection vulnerability
app.get('/users', (req, res) => {
    const userId = req.query.id;
    // UNSAFE: Direct string concatenation
    db.query(`SELECT * FROM users WHERE id = ${userId}`, (err, result) => {
        res.json(result);
    });
});

// 2. XSS vulnerability
app.post('/comment', (req, res) => {
    const comment = req.body.comment;
    // UNSAFE: Direct DOM injection
    res.send(`<div>${comment}</div>`);
});

// 3. Hardcoded credentials
const dbPassword = 'Admin@123'; // Security issue

After Fortify SCA Analysis & Fixes

// app.js - Secure code after remediation

// 1. Fixed SQL Injection using parameterized queries
app.get('/users', (req, res) => {
    const userId = req.query.id;
    // SAFE: Parameterized query
    db.query('SELECT * FROM users WHERE id = ?', [userId], (err, result) => {
        res.json(result);
    });
});

// 2. Fixed XSS using output encoding
const escapeHtml = require('escape-html');
app.post('/comment', (req, res) => {
    const comment = req.body.comment;
    // SAFE: HTML escaping
    res.send(`<div>${escapeHtml(comment)}</div>`);
});

// 3. Removed hardcoded credentials
const dbPassword = process.env.DB_PASSWORD; // From environment variables

Understanding Fortify Scan Results

Sample Output Format

{
  "issues": [
    {
      "id": "CWE-89",
      "severity": "High",
      "category": "SQL Injection",
      "file": "/src/routes/users.js",
      "line": 45,
      "description": "User input flows into SQL query without validation",
      "recommendation": "Use parameterized queries or stored procedures"
    },
    {
      "id": "CWE-79",
      "severity": "Medium",
      "category": "Cross-Site Scripting (XSS)",
      "file": "/src/views/comments.ejs",
      "line": 23,
      "description": "User input directly reflected in HTML output",
      "recommendation": "Implement proper output encoding"
    }
  ],
  "summary": {
    "total_issues": 15,
    "high_severity": 3,
    "medium_severity": 8,
    "low_severity": 4
  }
}

Severity Classification

Critical/High: Immediate attention required (SQLi, RCE, etc.)
Medium: Address in next development cycle (XSS, CSRF, etc.)
Low: Consider fixing (information disclosure, etc.)

Integrating Fortify SCA into CI/CD Pipeline

GitHub Actions Integration

# .github/workflows/fortify-scan.yml
name: Fortify SAST Scan

on: [push, pull_request]

jobs:
  fortify-scan:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Set up Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'

    - name: Install dependencies
      run: npm ci

    - name: Download Fortify SCA
      run: |
        wget https://download.fortify.com/sca/fortify-sca-latest.zip
        unzip fortify-sca-latest.zip

    - name: Run Fortify Scan
      run: |
        ./fortify-sca/bin/sourceanalyzer -b ${{ github.run_id }} -clean
        ./fortify-sca/bin/sourceanalyzer -b ${{ github.run_id }} **/*.js
        ./fortify-sca/bin/fortifyclient start scan -b ${{ github.run_id }}

    - name: Upload Results
      uses: actions/upload-artifact@v3
      with:
        name: fortify-results
        path: fortify-reports/

GitLab CI/CD Integration

# .gitlab-ci.yml
stages:
  - test
  - security

fortify_sast:
  stage: security
  image: node:18
  before_script:
    - apt-get update && apt-get install -y wget unzip
    - wget https://download.fortify.com/sca/fortify-sca-latest.zip
    - unzip fortify-sca-latest.zip
  script:
    - npm ci
    - ./fortify-sca/bin/sourceanalyzer -b $CI_PIPELINE_ID -clean
    - ./fortify-sca/bin/sourceanalyzer -b $CI_PIPELINE_ID **/*.js
    - ./fortify-sca/bin/fortifyclient start scan -b $CI_PIPELINE_ID
  artifacts:
    paths:
      - fortify-reports/
    when: always

Best Practices for SAST Implementation

Regular Scanning Schedule
Pre-commit hooks: Scan before each commit

Nightly builds: Comprehensive scans during off-hours
Release gates: Mandatory scans before production deployment

Tuning & Customization

# Custom rule pack configuration
com.fortify.sca.CustomRules.Path=/path/to/custom/rules.xml
com.fortify.sca.SuppressionFilter.Path=/path/to/false-positives.xml
com.fortify.sca.Severity.Threshold=Medium

Developer Education
Remediation workshops: How to fix identified issues
Secure coding training: Preventing vulnerabilities at source
Knowledge sharing: Internal security champions program

Comparison with Other SAST Tools

Feature	Fortify SCA	Checkmarx	CodeQL
Language Support	25+ languages	25+ languages	10+ languages
Analysis Depth	Deep flow analysis	Flow analysis	Semantic analysis
Integration	Extensive CI/CD plugins	Good integration	GitHub native
Learning Curve	Moderate to steep	Moderate	Moderate
Reporting	Enterprise-grade	Comprehensive	GitHub-focused

Common Challenges & Solutions

Challenge	Solution
False Positives	Create suppression filters for known false positives
Long Scan Times	Implement incremental scanning
Complex Setup	Use containerized deployment
High Resource Usage	Optimize scan configurations and schedule off-hours
Developer Resistance	Provide training and integrate smoothly into workflow

Challenge 1: False Positives

Solution: Create suppression filters for known false positives

<!-- false-positives.xml -->
<SuppressionFilters>
  <Suppress>
    <RuleID>CWE-78</RuleID>
    <File>.*legacy-code\.js</File>
  </Suppress>
</SuppressionFilters>

Challenge 2: Long Scan Times

Solution: Implement incremental scanning

## Only scan changed files
sourceanalyzer -b myApp -incremental

Challenge 3: Complex Setup

Solution: Use containerized deployment

# Dockerfile for Fortify SCA
FROM node:18
RUN wget https://download.fortify.com/sca/fortify-sca-latest.zip
RUN unzip fortify-sca-latest.zip
COPY . /app
WORKDIR /app
CMD ["./run-fortify-scan.sh"]

Conclusion

Fortify Static Code Analyzer provides robust security scanning for applications across multiple programming languages. While it requires initial setup and configuration, its comprehensive vulnerability detection and detailed remediation guidance make it valuable for enterprise security programs.

Key takeaways:

SAST tools like Fortify catch vulnerabilities early in development
Integration with CI/CD pipelines enables automated security testing
Regular scans and developer education significantly improve application security
Proper tuning reduces false positives and increases tool effectiveness

Additional Resources

OWASP SAST Tools List
Fortify SCA Documentation
NIST Application Security Guidelines
Secure Coding Practices Checklist

A Real-World Comparison of Testing Management Tools: GitHub Actions vs GitLab CI/CDs

Hashira Belén Vargas Candia — Thu, 04 Dec 2025 05:20:49 +0000

Article by: Hashira Belén Vargas Candia
Systems Engineering Student – CI/CD & DevOps Focus

Introduction
In modern software development, continuous integration and delivery (CI/CD) are essential for ensuring code quality and fast deployments. Automated testing tools allow test suites to run automatically with every code change. In this article, I will compare two of the most popular tools: GitHub Actions and GitLab CI/CD, providing real configuration examples.

GitHub Actions
Overview
GitHub Actions is the native CI/CD solution integrated directly into GitHub. It allows workflow automation using YAML files in the .github/workflows directory. It is highly flexible, with a marketplace of pre-built actions and support for Docker containers.

Example Configuration

# .github/workflows/run-tests.yml
name: Run Tests

on:
  push:
    branches: [ main, develop ]
  pull_request:
    branches: [ main ]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
    - name: Checkout code
      uses: actions/checkout@v3

    - name: Set up Node.js
      uses: actions/setup-node@v3
      with:
        node-version: '18'

    - name: Install dependencies
      run: npm ci

    - name: Run unit tests
      run: npm test

    - name: Run integration tests
      run: npm run test:integration

    - name: Upload coverage reports
      uses: codecov/codecov-action@v3

GitLab CI/CD

Overview
GitLab CI/CD is the continuous integration tool included within the GitLab platform. It is configured using a .gitlab-ci.yml file in the repository root. It offers visual pipelines, deployment environments, and deep integration with the DevOps lifecycle.

Example Configuration

# .gitlab-ci.yml
stages:
  - test
  - deploy

unit_tests:
  stage: test
  image: node:18-alpine
  script:
    - npm ci
    - npm test
  artifacts:
    when: always
    paths:
      - coverage/
    reports:
      junit: junit.xml

integration_tests:
  stage: test
  image: node:18-alpine
  services:
    - postgres:latest
  variables:
    POSTGRES_DB: test_db
    POSTGRES_USER: runner
    POSTGRES_PASSWORD: ""
  script:
    - npm ci
    - npm run test:integration

pages:
  stage: deploy
  script:
    - npm run build:coverage
  artifacts:
    paths:
      - public

Detailed Comparison

Feature	GitHub Actions	GitLab CI/CD
Native Integration	With GitHub (perfect if you use GitHub)	With GitLab (complete DevOps ecosystem)
Configuration Syntax	YAML with reusable actions	YAML with defined stages and jobs
Marketplace/Pre-built Actions	Extensive GitHub Marketplace	Reusable templates and components
Visual Environments	Basic but functional	More detailed visual pipelines
Pricing for Private Repos	2000 free minutes/month	400 free minutes/month on SaaS free tier
Self-hosted Runners	Yes (runners)	Yes (GitLab runners)
Cache and Artifacts	Built-in support	Very robust with configurable storage
Kubernetes Integration	Yes (via actions)	Native and very strong

Real-World Use Case: Testing Pipeline for a REST API
Context
I developed a REST API with Node.js/Express that requires:

Unit tests (Jest)

Integration tests with PostgreSQL

Load testing (optional)

Coverage reports

GitHub Actions Solution

- name: Run load tests
  if: github.ref == 'refs/heads/main'
  run: |
    npm install -g artillery
    artillery run load-test.yml
GitLab CI/CD Solution
yaml
performance_tests:
  stage: test
  only:
    - main
  script:
    - npm install -g artillery
    - artillery run load-test.yml

Both tools allow running load tests only on the main branch, optimizing resource usage.

Tool Selection Recommendations

Choose GitHub Actions if:

Your repository is already on GitHub
You need integration with many third-party tools*
You prefer a community-driven actions ecosystem
Your team is small to medium and values simplicity

Choose GitLab CI/CD if:

You already use GitLab for repository management
You need a complete DevOps pipeline (from issues to deploy)
You require native integration with Kubernetes
You work in a large team with auditing and security needs

Conclusion
Both GitHub Actions and GitLab CI/CD are powerful tools for test automation. The choice mainly depends on where your code is hosted and your specific DevOps workflow needs.

GitHub Actions stands out for its simplicity and vast action ecosystem, while GitLab CI/CD offers deeper integration with the full development lifecycle. Both enable robust, scalable, and maintainable testing pipelines.

Applying API Testing Frameworks: Real-World Examples with Swagger and JUnit

Hashira Belén Vargas Candia — Tue, 04 Nov 2025 07:11:07 +0000

Introduction

In today's software development landscape, APIs (Application Programming Interfaces) are essential for enabling communication between different systems. Ensuring that these APIs function correctly is crucial, which is why API testing is an integral part of the development process.

This article explores how to apply API testing frameworks in real-world scenarios, using Swagger and JUnit as examples. These frameworks help automate and streamline the testing process, ensuring that APIs are functional, secure, and performant.

What is an API Testing Framework?

An API testing framework is a set of tools, libraries, and processes that facilitate the testing of APIs. The goal of such a framework is to standardize the testing process, making it easier to write, run, and maintain tests for APIs across different endpoints and services.

Benefits of Using an API Testing Framework:

Automation: Reduces manual effort by automating repetitive tasks.
Consistency: Ensures uniformity in testing across various API endpoints.
Scalability: Makes it easier to scale tests as the system grows.
Integration: Can be integrated into Continuous Integration (CI) and Continuous Deployment (CD) pipelines for continuous testing.

Using Swagger for API Testing

Swagger (now known as OpenAPI) is one of the most widely used frameworks for defining and testing APIs. It allows developers to define their APIs in a standardized format, which can then be used for documentation and testing.

Example 1: Testing API with Swagger

To test an API with Swagger, first define the API endpoints in a Swagger (OpenAPI) specification file. Here's a simple example of how a user API might be defined in Swagger:

openapi: 3.0.0
info:
  title: User API
  description: API for managing users in a system
  version: 1.0.0
paths:
  /users/{id}:
    get:
      summary: Get a user by ID
      parameters:
        - in: path
          name: id
          required: true
          schema:
            type: integer
            example: 1
      responses:
        200:
          description: User found
          content:
            application/json:
              schema:
                type: object
                properties:
                  id:
                    type: integer
                  name:
                    type: string
                example:
                  id: 1
                  name: "John Doe"
        404:
          description: User not found

In this Swagger file, we've defined a GET request to retrieve a user by their ID.

Testing with Swagger Inspector

You can use Swagger Inspector to validate the API by running tests directly from the Swagger specification.

To use Swagger Inspector, simply enter the Swagger URL or upload the Swagger JSON/YAML file, and it will generate test requests for each defined endpoint.

Using JUnit and RestAssured for API Testing in Java

JUnit is one of the most widely used testing frameworks for Java. When combined with RestAssured, a library designed for testing REST APIs, JUnit provides a powerful solution for testing APIs in Java.

Example 2: Testing an API with JUnit and RestAssured

First, add RestAssured and JUnit to your pom.xml:

<dependency>
    <groupId>io.rest-assured</groupId>
    <artifactId>rest-assured</artifactId>
    <version>4.3.3</version>
    <scope>test</scope>
</dependency>

<dependency>
    <groupId>org.junit.jupiter</groupId>
    <artifactId>junit-jupiter-api</artifactId>
    <version>5.7.0</version>
    <scope>test</scope>
</dependency>

Now, let's write a simple JUnit test to verify the GET request for the /users/{id} endpoint.

import io.restassured.RestAssured;
import org.junit.jupiter.api.Test;
import static org.hamcrest.Matchers.*;

public class UserApiTest {

    @Test
    public void testGetUser() {
        RestAssured.baseURI = "https://reqres.in/api"; // Base URL

        RestAssured
            .given()
                .pathParam("id", 1) // Path parameter
            .when()
                .get("/users/{id}") // GET request to /users/{id}
            .then()
                .statusCode(200) // Assert that the status code is 200 (OK)
                .body("data.id", equalTo(1)) // Validate that the ID is 1
                .body("data.first_name", equalTo("George")); // Validate first_name
    }
}

In this example:

RestAssured is used to send a GET request to the /users/{id} endpoint.
JUnit is used to validate that the response code is 200 and that the returned ID and first_name match the expected values.

Step 3: Running the Test
You can run the test using Maven:

mvn test

This will execute the test, and JUnit will validate the response based on the conditions defined in the test.

Integrating API Tests into CI/CD Pipelines

Integrating API tests into your CI/CD pipeline ensures that your tests run automatically with each code change. This helps identify issues early in the development process.

Integrating with Jenkins

To run the JUnit tests in Jenkins, you can add the following steps to your Jenkinsfile:

pipeline {
    agent any
    stages {
        stage('Build') {
            steps {
                sh 'mvn clean install'
            }
        }
        stage('Test') {
            steps {
                sh 'mvn test' // Run JUnit tests
            }
        }
    }
}

This Jenkins pipeline will trigger the JUnit tests automatically every time code is committed to your repository.

Running Swagger Tests in CI/CD

You can also integrate Swagger Inspector in a CI/CD pipeline by calling the Swagger API using a curl command in your pipeline to validate the API against your Swagger definitions.

Best Practices for API Testing

When applying frameworks for API testing, consider the following best practices:

Organize Your Tests: Group your tests by API category or functionality for easier maintenance.
Use Data-Driven Testing: Test different data sets to ensure the API behaves correctly with a variety of inputs.
Mock APIs: Use mock servers to simulate APIs during testing, especially when the actual API is not available.
Automate Your Tests: Automate your API tests and integrate them into the CI/CD pipeline for continuous testing.

Conclusion

API testing is an essential part of ensuring the functionality, security, and performance of your APIs. By using Swagger for API documentation and JUnit with RestAssured for testing, you can streamline the testing process and ensure that your APIs are thoroughly tested.

Integrating these tools into your CI/CD pipeline allows for continuous testing, ensuring your APIs remain reliable and meet the expected requirements.

References

Swagger Documentation
JUnit 5 Documentation
RestAssured Documentation
Top 15 API Testing Tools in 2022