Forem: Renzo Fernando LOYOLA VILCA CHOQUE

Secure Your Python App Using Bandit as a SAST Tool

Renzo Fernando LOYOLA VILCA CHOQUE — Sat, 06 Dec 2025 01:18:08 +0000

Static Application Security Testing (SAST) tools help you detect vulnerabilities directly in your source code before the application is executed or deployed. In this article, you will see how to use Bandit, a Python‑focused SAST tool, to scan a Python application and improve its security posture.

What Is SAST and Why It Matters
SAST refers to techniques and tools that analyze source code, bytecode or binaries to find security weaknesses without running the application. These tools search for patterns related to insecure practices such as injection, unsafe system calls, weak cryptography, or hardcoded secrets.

Running SAST early in the development lifecycle allows teams to detect and fix issues before they reach production, which reduces both risk and remediation cost. Integrating SAST into everyday workflows (IDE checks, pre‑commit hooks or CI/CD pipelines) transforms security from a late, manual step into a continuous, automated practice.

Meet Bandit: A Python Security Linter
Bandit is an open source security linter designed to find common security issues in Python code. It parses Python files, builds an abstract syntax tree (AST), and runs a set of security tests to detect problems such as hardcoded passwords, use of unsafe functions like exec, insecure random generators, weak hashes, or risky XML and subprocess usage.

Because Bandit understands Python syntax and idioms, it can provide more precise findings than generic text‑based scanners for this language. It is distributed through PyPI, actively maintained by the PyCQA community, and can be easily integrated into local development workflows and CI/CD pipelines.

Setting Up Bandit in Your Project
To use Bandit, you only need a working Python environment and pip. Many developers prefer to create a virtual environment so that security tools and project dependencies do not conflict.

Example setup steps (run in your terminal):

Create and activate a virtual environment (optional).

Install Bandit with pip: pip install bandit.

Optionally, install extra features like TOML support, baseline management or SARIF output using extras such as bandit[toml], bandit[baseline] or bandit[sarif].

After installation, the bandit command becomes available in your shell so you can run it from any project directory.

Scanning a Python Application with Bandit
Once Bandit is installed, you can scan either a single file or an entire project directory. The most common workflow is to navigate to the root of your Python project and run Bandit recursively.

Typical examples:

Scan a single file: bandit app.py

Scan a whole project recursively: bandit -r .

When the scan finishes, Bandit prints a report showing each issue it found, along with fields like severity, confidence, file path, line number and a short description. You can also change the output format to JSON, XML, HTML, YAML and others, which is useful for storing results or integrating with dashboards.

Understanding Bandit’s Output
Bandit assigns two key attributes to each finding: severity and confidence. Severity indicates how serious the potential vulnerability is (for example low, medium or high), while confidence reflects how certain Bandit is that the pattern represents a real security problem.

High‑severity, high‑confidence issues typically indicate dangerous patterns such as use of weak cryptographic functions, insecure temporary files, unsafe XML parsers or shell commands with untrusted input. Developers should review these findings in context, confirm whether they are valid issues, and then apply fixes such as input validation, parameterization, replacing weak algorithms or refactoring dangerous code.

Applying Bandit to a Sample Scenario
Imagine a small Python web application that performs file operations, calls external commands and processes user input. Bandit can help identify if:

Temporary files are created using insecure methods.

User input is passed directly into shell commands or SQL queries.

Insecure modules like telnetlib or weak hash functions like md5 are in use.

Running bandit -r . from the project root will reveal these patterns with line numbers and explanations, making it easier to refactor the application before deployment.

Integrating Bandit into CI/CD
The real power of a SAST tool appears when it becomes part of your automated pipelines. With Bandit, you can add a CI job that installs dependencies, runs bandit -r ., and fails the pipeline if new high‑severity issues are introduced.

For example, in a GitHub Actions or GitLab CI pipeline, you can:

Use a Python base image, install Bandit and run it as part of your test stage.

Configure Bandit to output JSON or SARIF and upload that report as a pipeline artifact or feed it into security dashboards.

Optionally, use a baseline file to compare current results against previous scans, so only new findings break the build.

This approach ensures every pull request is checked for security issues, not only for functionality or style.

Best Practices When Using Bandit
To get the most value from Bandit, consider these practices:

Run Bandit locally as part of a pre‑commit hook so that insecure patterns are caught before code is pushed.

Adjust severity and confidence thresholds to match your project’s risk tolerance, focusing on high‑impact issues first.

Regularly review and update the configuration (for example .bandit.yml) to skip false positives or define project‑specific rules.

Combine Bandit with other security practices such as dependency scanning, dynamic testing and manual code review.

Bandit is not a silver bullet, but it is a lightweight and effective way to bring security awareness into everyday Python development.

Limitations and Complementary Tools
Bandit focuses on static analysis of Python source code, so it does not replace dynamic application security testing or runtime protection. It may also miss complex logic issues that require deeper understanding of business rules, which is why human review remains essential.

For a more complete security strategy, combine Bandit with tools that check open‑source dependencies, perform dynamic scans against running environments and monitor production systems. Even with these limitations, integrating Bandit as your SAST tool for Python significantly raises your application’s security baseline with relatively low effort

Applying API testing frameworks: real-world code examples

Renzo Fernando LOYOLA VILCA CHOQUE — Sat, 06 Dec 2025 00:53:35 +0000

Applying API testing frameworks: real-world code examples
Modern applications dependen de APIs para conectar frontends, servicios internos y terceros. Validar estas APIs de forma automática es clave para evitar regresiones y detectar errores antes de llegar a producción. En este artículo verás cómo aplicar marcos de prueba de API con ejemplos reales usando Postman (JavaScript) y Rest Assured (Java), y cómo integrarlos en un flujo de CI/CD.

Why API testing matters
API testing permite validar lógica de negocio, contratos y reglas de seguridad sin necesidad de una interfaz gráfica. Cuando se integra en pipelines de CI/CD, ayuda a detectar fallos de manera temprana y a mantener lanzamientos frecuentes pero estables. Además, automatizar estas pruebas reduce el trabajo manual del QA y mejora la confianza en cada despliegue.

Choosing an API testing framework
Existen múltiples herramientas para probar APIs: Postman, Rest Assured, Karate, JMeter, SoapUI, entre otras. Cada una ofrece ventajas según el lenguaje, el tipo de proyecto y el nivel de experiencia del equipo. En este artículo nos centraremos en dos opciones muy usadas en la industria: Postman para flujos rápidos y colaborativos, y Rest Assured para pruebas integradas en suites Java.

Postman: testing with JavaScript
Postman es una herramienta muy popular para diseñar, documentar y probar APIs, tanto de forma manual como automatizada. Permite agrupar peticiones en Collections, usar entornos con variables, y añadir scripts en JavaScript para ejecutar aserciones sobre las respuestas.

Un flujo típico de prueba funcional en Postman incluye:

Definir la petición (método, URL, headers, body).

Añadir scripts en la pestaña “Tests” para validar el resultado.

Ejecutar la Collection de manera local o en un pipeline CI/CD.

Real-world example: validating a GET endpoint in Postman
Supongamos una API de librería con el endpoint GET /books/{id} que devuelve los detalles de un libro. El objetivo de la prueba es validar que el servicio responde con código 200 y que el cuerpo incluye campos como id, title y author con datos válidos.

En Postman, la prueba podría incluir aserciones como:

js
pm.test("Status code is 200", function () {
pm.response.to.have.status(200);
});

pm.test("Response body has required fields", function () {
const json = pm.response.json();
pm.expect(json).to.have.property("id");
pm.expect(json).to.have.property("title");
pm.expect(json).to.have.property("author");
});

pm.test("Book id matches requested id", function () {
const json = pm.response.json();
const requestedId = pm.request.url.variables.get("id");
pm.expect(json.id.toString()).to.eql(requestedId);
});
Este tipo de script se ejecuta automáticamente después de cada llamada y te permite validar tanto el código de estado como la estructura del JSON.

Data-driven tests with Postman
En escenarios reales, es habitual probar el mismo endpoint con distintos datos de entrada. Postman soporta pruebas orientadas a datos usando archivos CSV o JSON, donde cada fila representa un conjunto de variables para la ejecución.

Por ejemplo, un archivo CSV podría contener varios bookId y valores esperados, y la Collection Runner los iterará de manera automática. Esto permite cubrir casos positivos y negativos (IDs válidos, inexistentes o inválidos) sin duplicar manualmente las peticiones.

Rest Assured: Java-based API testing
Rest Assured es un framework para pruebas de API en Java que simplifica el envío de peticiones HTTP y la validación de respuestas. Se integra bien con TestNG o JUnit, lo que facilita su uso dentro de suites automatizadas y pipelines de CI/CD.

Su enfoque fluido permite escribir pruebas legibles, y combinarlo con librerías como Hamcrest para aserciones expresivas sobre JSON y XML. Además, soporta múltiples métodos HTTP, autenticación, parámetros, logs y manejo de serialización/deserialización.

Real-world example: Rest Assured GET test
Tomando el mismo escenario de GET /books/{id}, una prueba en Rest Assured podría validar el status code y campos clave de la respuesta JSON.

java
import static io.restassured.RestAssured.;
import static org.hamcrest.Matchers.;
import org.testng.annotations.Test;

public class BookApiTest {

@Test
public void getBookById_shouldReturnValidBook() {
    given()
        .baseUri("https://api.example.com")
        .basePath("/books/{id}")
        .pathParam("id", 1)
    .when()
        .get()
    .then()
        .statusCode(200)
        .body("id", equalTo(1))
        .body("title", notNullValue())
        .body("author", notNullValue());
}

}
Este tipo de prueba se puede ejecutar junto con el resto del suite de tests de backend, formando parte del proceso de build.

Creating reusable components in Rest Assured
En casos reales, resulta útil extraer configuraciones repetidas como baseUri, headers comunes o autenticación a una clase base. De esta forma, las pruebas se enfocan en el comportamiento, no en el detalle de configuración de cada endpoint.

Por ejemplo, se puede definir una clase BaseApiTest que configure Rest Assured en un método @BeforeClass y luego extenderla desde las clases que representan cada módulo de la API (books, users, orders, etc.).

Testing authenticated APIs
Muchos servicios exponen endpoints protegidos mediante API keys, tokens Bearer u OAuth2. Tanto Postman como Rest Assured ofrecen soporte para este tipo de autenticación, ya sea configurando headers, usando helpers integrados o generando tokens previos a las pruebas.

En Rest Assured, por ejemplo, se puede añadir un header de autorización de forma global o en cada prueba:

java
given()
.baseUri("https://api.example.com")
.header("Authorization", "Bearer " + token)
.when()
.get("/books")
.then()
.statusCode(200);
En Postman, puedes almacenar el token en una variable de entorno y referenciarlo en el header Authorization mediante {{token}}.

Integrating API tests into CI/CD
El verdadero valor de estos marcos se ve cuando se integran en pipelines de CI/CD como GitHub Actions, Jenkins o GitLab CI. La idea es ejecutar suites de pruebas de API en cada push o antes de un despliegue para evitar que cambios en el código rompan contratos existentes.

Algunos enfoques habituales son:

Ejecutar Collections de Postman mediante Newman en un job del pipeline.

Ejecutar tests de Rest Assured con Maven/Gradle como parte del stage de test.

Publicar reportes (HTML, JUnit) como artefactos del pipeline para su revisión.

Example: running Postman tests in CI
Newman, el CLI de Postman, permite ejecutar collections dentro de un flujo automatizado. Un paso típico en un pipeline podría incluir un comando como:

bash
newman run LibraryAPI.postman_collection.json \
-e staging.postman_environment.json \
--reporters cli,junit \
--reporter-junit-export newman-report.xml
Ese reporte puede ser consumido por la plataforma de CI/CD para marcar el build como exitoso o fallido según los resultados de las pruebas.

Example: running Rest Assured in CI
Para proyectos Java, lo más habitual es ejecutar los tests de Rest Assured junto con el resto de pruebas unitarias e integradas. En un pipeline que use Maven, bastaría con un job que ejecute mvn test y recoja los informes generados.

Combinado con herramientas de reporte como surefire-report o plugins de informes HTML, es posible ver en detalle qué endpoints fallaron, qué payload se envió y cuál fue la respuesta recibida.

Putting it all together
Aplicar marcos de prueba de API en proyectos reales significa ir más allá de pruebas manuales puntuales y construir suites automatizadas que vivan junto al código. Usando Postman puedes cubrir rápidamente escenarios funcionales y colaborativos, mientras que Rest Assured te permite integrar pruebas de API directamente en tu base de código Java y pipeline de CI/CD.

Al combinar ambos enfoques, obtienes una cobertura robusta: validaciones funcionales, pruebas con datos, escenarios autenticados y ejecución continua en cada cambio. Esto se traduce en APIs más confiables, menos incidentes en producción y un ciclo de desarrollo más seguro y predecible

Securing Infrastructure as Code with Checkov: A Practical SAST Approach

Renzo Fernando LOYOLA VILCA CHOQUE — Sat, 06 Dec 2025 00:41:48 +0000

Introduction
Infrastructure as Code (IaC) has revolutionized how we manage and deploy cloud resources. However, with great power comes great responsibility. Security misconfigurations in IaC templates can lead to serious vulnerabilities in production environments. This is where Static Application Security Testing (SAST) tools like Checkov come into play.

In this article, we'll explore how to implement Checkov, a powerful open-source SAST tool, to scan and secure your Infrastructure as Code across multiple platforms including Terraform, CloudFormation, Kubernetes, and more.

What is Checkov?
Checkov is a static code analysis tool developed by Bridgecrew (now part of Palo Alto Networks) that scans infrastructure code for security and compliance misconfigurations. It supports:

Terraform
CloudFormation
Kubernetes
Helm
ARM Templates
Serverless Framework
Docker
And many more...
Why Use SAST for Infrastructure as Code?
Early Detection: Identify security issues before they reach production
Compliance: Ensure adherence to industry standards (CIS, PCI-DSS, HIPAA)
Cost Reduction: Fix issues early in the development cycle
Automation: Integrate seamlessly into CI/CD pipelines
Policy as Code: Define and enforce organizational security policies

Getting Started with Checkov
Installation
Checkov can be installed using pip:

pip install checkov
Or using Docker:

docker pull bridgecrew/checkov
Basic Usage
Scan a Terraform directory:

checkov -d /path/to/terraform
Scan a specific file:

checkov -f main.tf
Practical Example: Securing Terraform Code
Let's examine a vulnerable Terraform configuration and how Checkov identifies the issues.

Vulnerable Configuration

main.tf - INSECURE EXAMPLE

resource "aws_s3_bucket" "data_bucket" {
bucket = "my-data-bucket"

# Missing encryption
# Missing versioning
# Missing logging
}

resource "aws_security_group" "web_sg" {
name = "web-security-group"
description = "Security group for web servers"

ingress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"] # Too permissive!
}
}

resource "aws_db_instance" "database" {
allocated_storage = 20
engine = "mysql"
instance_class = "db.t3.micro"
username = "admin"
password = "hardcodedpassword123" # Hardcoded password!
skip_final_snapshot = true

# Missing encryption
# Publicly accessible by default
}
Running Checkov
checkov -f main.tf --output json --output-file results.json
Checkov Output
Checkov will identify multiple security issues:

Check: CKV_AWS_18: "Ensure the S3 bucket has access logging enabled"
Check: CKV_AWS_19: "Ensure the S3 bucket has server-side encryption enabled"
Check: CKV_AWS_21: "Ensure the S3 bucket has versioning enabled"
Check: CKV_AWS_23: "Ensure Security Group does not allow ingress from 0.0.0.0/0 to port 22"
Check: CKV_AWS_16: "Ensure RDS database is encrypted at rest"
Check: CKV_AWS_41: "Ensure RDS instance has IAM authentication enabled"
Secure Configuration
Now let's fix these issues:

main.tf - SECURE VERSION

resource "aws_s3_bucket" "data_bucket" {
bucket = "my-data-bucket"
}

resource "aws_s3_bucket_versioning" "data_bucket_versioning" {
bucket = aws_s3_bucket.data_bucket.id
versioning_configuration {
status = "Enabled"
}
}

resource "aws_s3_bucket_server_side_encryption_configuration" "data_bucket_encryption" {
bucket = aws_s3_bucket.data_bucket.id

rule {
apply_server_side_encryption_by_default {
sse_algorithm = "AES256"
}
}
}

resource "aws_s3_bucket_logging" "data_bucket_logging" {
bucket = aws_s3_bucket.data_bucket.id

target_bucket = aws_s3_bucket.log_bucket.id
target_prefix = "log/"
}

resource "aws_security_group" "web_sg" {
name = "web-security-group"
description = "Security group for web servers"

ingress {
from_port = 443
to_port = 443
protocol = "tcp"
cidr_blocks = ["10.0.0.0/8"] # Restricted to internal network
}

egress {
from_port = 0
to_port = 0
protocol = "-1"
cidr_blocks = ["0.0.0.0/0"]
}
}

resource "aws_db_instance" "database" {
allocated_storage = 20
engine = "mysql"
instance_class = "db.t3.micro"
username = "admin"
password = var.db_password # Using variable instead
skip_final_snapshot = false

storage_encrypted = true
iam_database_authentication_enabled = true
publicly_accessible = false

backup_retention_period = 7
enabled_cloudwatch_logs_exports = ["error", "general", "slowquery"]
}
Integrating Checkov into CI/CD
GitHub Actions Example
name: IaC Security Scan

on: [push, pull_request]

jobs:
checkov:
runs-on: ubuntu-latest
steps:
- name: Checkout code
uses: actions/checkout@v3

  - name: Set up Python
    uses: actions/setup-python@v4
    with:
      python-version: '3.9'

  - name: Install Checkov
    run: pip install checkov

  - name: Run Checkov
    run: |
      checkov -d . --output cli --output json --output-file checkov-report.json

  - name: Upload results
    uses: actions/upload-artifact@v3
    if: always()
    with:
      name: checkov-report
      path: checkov-report.json

GitLab CI Example
checkov:
stage: test
image: bridgecrew/checkov:latest
script:
- checkov -d . --output cli --output junitxml --output-file checkov-report.xml
artifacts:
reports:
junit: checkov-report.xml
Custom Policies
Checkov allows you to create custom policies using Python:

from checkov.common.models.enums import CheckResult, CheckCategories
from checkov.terraform.checks.resource.base_resource_check import BaseResourceCheck

class S3BucketEncryption(BaseResourceCheck):
def init(self):
name = "Ensure S3 bucket is encrypted with KMS"
id = "CKV_AWS_CUSTOM_1"
supported_resources = ['aws_s3_bucket']
categories = [CheckCategories.ENCRYPTION]
super().init(name=name, id=id, categories=categories,
supported_resources=supported_resources)

def scan_resource_conf(self, conf):
    if 'server_side_encryption_configuration' in conf:
        encryption_config = conf['server_side_encryption_configuration'][0]
        if 'rule' in encryption_config:
            rule = encryption_config['rule'][0]
            if 'apply_server_side_encryption_by_default' in rule:
                encryption = rule['apply_server_side_encryption_by_default'][0]
                if encryption.get('sse_algorithm') == ['aws:kms']:
                    return CheckResult.PASSED
    return CheckResult.FAILED

check = S3BucketEncryption()
Best Practices
Run Checkov Early: Integrate it into your development workflow
Use Suppressions Wisely: Document why certain checks are suppressed
Keep Checkov Updated: New checks are added regularly
Set Baseline: Use --baseline to track improvements over time
Combine with Other Tools: Use alongside dynamic testing and manual reviews
Educate Your Team: Ensure developers understand the security implications
Suppressing False Positives
Sometimes you need to suppress legitimate findings:

resource "aws_security_group" "special_case" {
name = "special-sg"

#checkov:skip=CKV_AWS_23:This SG is for internal load balancer
ingress {
from_port = 80
to_port = 80
protocol = "tcp"
cidr_blocks = ["0.0.0.0/0"]
}
}
Measuring Success
Track these metrics to measure the effectiveness of Checkov:

Vulnerability Detection Rate: Number of issues found per scan
Fix Time: Time from detection to remediation
False Positive Rate: Percentage of findings that are not actual issues
Coverage: Percentage of infrastructure code being scanned
Compliance Score: Pass rate against security benchmarks
Conclusion
Implementing SAST tools like Checkov is essential for maintaining secure infrastructure as code. By catching security issues early in the development cycle, you can:

Reduce security risks in production
Ensure compliance with industry standards
Foster a security-first culture
Save time and money on remediation
Start small by integrating Checkov into one project, measure the results, and gradually expand coverage across your organization. Security is a journey, not a destination, and tools like Checkov are invaluable companions along the way.

References
Checkov Official Documentation
OWASP Source Code Analysis Tools
Terraform Security Best Practices
CIS Benchmarks

Dominando las Pruebas de API con Postman: Ejemplos del Mundo Real

Renzo Fernando LOYOLA VILCA CHOQUE — Thu, 04 Dec 2025 13:04:09 +0000

Introducción

En el desarrollo de software moderno, las APIs (Interfaces de Programación de Aplicaciones) son la columna vertebral de la comunicación entre sistemas. Postman se ha consolidado como una de las herramientas más populares y poderosas para probar, documentar y automatizar APIs. En este artículo, exploraremos cómo aplicar Postman en escenarios del mundo real, con ejemplos prácticos que puedes implementar inmediatamente.

¿Por qué Postman?

Postman no es solo un cliente HTTP; es una plataforma completa para el desarrollo de APIs que ofrece:

Interfaz intuitiva: Ideal para principiantes y expertos
Automatización de pruebas: Scripts JavaScript para validaciones complejas
Colecciones organizadas: Agrupa solicitudes relacionadas
Variables de entorno: Facilita el cambio entre dev, staging y producción
Integración CI/CD: Compatible con Newman para pipelines automatizados
Colaboración en equipo: Espacios de trabajo compartidos

Caso de Uso 1: Prueba de API RESTful de E-commerce

Imaginemos que estamos probando una API de una tienda en línea que gestiona productos.

Escenario: Obtener lista de productos

// GET https://api.tienda.com/v1/productos

// En la pestaña "Tests" de Postman:
pm.test("El código de estado es 200", function () {
    pm.response.to.have.status(200);
});

pm.test("La respuesta es JSON", function () {
    pm.response.to.be.json;
});

pm.test("La respuesta contiene productos", function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData).to.be.an('array');
    pm.expect(jsonData.length).to.be.above(0);
});

pm.test("Cada producto tiene campos requeridos", function () {
    const productos = pm.response.json();
    productos.forEach(producto => {
        pm.expect(producto).to.have.property("id");
        pm.expect(producto).to.have.property("nombre");
        pm.expect(producto).to.have.property("precio");
        pm.expect(producto).to.have.property("stock");
    });
});

Escenario: Crear un nuevo producto (POST)

// POST https://api.tienda.com/v1/productos
// Body (JSON):
{
    "nombre": "Laptop Dell XPS 15",
    "precio": 1299.99,
    "categoria": "Electrónica",
    "stock": 25
}

// Tests:
pm.test("Producto creado exitosamente - 201", function () {
    pm.response.to.have.status(201);
});

pm.test("La respuesta contiene el ID del producto", function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData).to.have.property("id");

    // Guardar el ID para usar en solicitudes posteriores
    pm.environment.set("producto_id", jsonData.id);
});

pm.test("El precio se guardó correctamente", function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData.precio).to.eql(1299.99);
});

Caso de Uso 2: Autenticación y Autorización

Las APIs del mundo real requieren autenticación. Veamos cómo manejar tokens JWT.

Paso 1: Login y captura de token

// POST https://api.tienda.com/v1/auth/login
// Body:
{
    "email": "usuario@ejemplo.com",
    "password": "password123"
}

// Tests:
pm.test("Login exitoso", function () {
    pm.response.to.have.status(200);
});

pm.test("Token JWT recibido", function () {
    const jsonData = pm.response.json();
    pm.expect(jsonData).to.have.property("token");

    // Guardar el token en variable de entorno
    pm.environment.set("jwt_token", jsonData.token);

    // Guardar timestamp de expiración
    pm.environment.set("token_expiry", jsonData.expiresIn);
});

Paso 2: Usar el token en solicitudes protegidas

// GET https://api.tienda.com/v1/usuario/perfil
// Headers: Authorization: Bearer {{jwt_token}}

// Pre-request Script para verificar token:
const token = pm.environment.get("jwt_token");

if (!token) {
    throw new Error("No hay token de autenticación. Ejecuta primero el login.");
}

// Tests:
pm.test("Acceso autorizado al perfil", function () {
    pm.response.to.have.status(200);
});

pm.test("Datos del usuario son correctos", function () {
    const usuario = pm.response.json();
    pm.expect(usuario).to.have.property("email");
    pm.expect(usuario).to.have.property("nombre");
    pm.expect(usuario.rol).to.eql("admin");
});

Conclusiones

Postman es mucho más que una herramienta para enviar solicitudes HTTP. Como hemos visto en estos ejemplos del mundo real:

Validación robusta: Podemos verificar códigos de estado, estructura de datos y lógica de negocio
Flujos complejos: Encadenamiento de solicitudes con variables dinámicas
Automatización: Integración perfecta con pipelines CI/CD mediante Newman
Colaboración: Espacios de trabajo compartidos facilitan el trabajo en equipo
Documentación viva: Las colecciones sirven como documentación ejecutable

Recursos Adicionales

Sobre el autor: Este artículo forma parte del Trabajo de Investigación N° 02 sobre Comparación de Frameworks de Pruebas de API, desarrollado como parte del curso de Calidad y Pruebas de Software.

Construyendo un Servidor MCP: Conectando Claude y VSCode a Herramientas Externas

Renzo Fernando LOYOLA VILCA CHOQUE — Thu, 04 Dec 2025 01:16:02 +0000

Introducción

El Protocolo de Contexto de Modelo (MCP) es un protocolo abierto revolucionario desarrollado por Anthropic que permite a asistentes de IA como Claude conectarse con fuentes de datos externas y herramientas. En este artículo, te guiaré a través de la construcción de tu propio servidor MCP que puede ser utilizado con Claude Desktop, VSCode y otros clientes compatibles.

¿Qué es MCP?

MCP proporciona una forma estandarizada para que los asistentes de IA interactúen con sistemas externos. Piensa en él como un adaptador universal que permite a Claude:

Acceder a bases de datos y APIs
Leer y escribir archivos
Ejecutar comandos
Interactuar con servicios web

El protocolo define una arquitectura cliente-servidor donde:

Clientes MCP (como Claude Desktop o VSCode) se conectan a servidores
Servidores MCP exponen capacidades específicas (recursos, herramientas y prompts)
La comunicación ocurre a través de JSON-RPC 2.0 sobre stdio o HTTP

Descripción General de la Arquitectura

Un servidor MCP consta de tres componentes principales:

1. Recursos

Los recursos son fuentes de datos que el servidor puede proporcionar a los clientes. Pueden ser:

Archivos de un sistema de archivos
Registros de bases de datos
Respuestas de APIs
Flujos de datos en tiempo real

2. Herramientas

Las herramientas son funciones que el cliente puede invocar a través del servidor:

Ejecutar comandos del sistema
Realizar cálculos
Interactuar con APIs externas
Manipular datos

3. Prompts

Los prompts son plantillas predefinidas que ayudan a estructurar las interacciones:

Plantillas de consultas
Patrones de comandos
Instrucciones de flujo de trabajo

Construyendo tu Primer Servidor MCP

Construyamos un servidor MCP simple paso a paso. Para este ejemplo, usaré Python, pero los servidores MCP pueden construirse en cualquier lenguaje.

Requisitos Previos

pip install mcp

Estructura Básica del Servidor

from mcp.server import Server
from mcp.types import Resource, Tool
import asyncio

app = Server("my-mcp-server")

@app.list_resources()
async def list_resources() -> list[Resource]:
    return [
        Resource(
            uri="file:///example.txt",
            name="Archivo de Ejemplo",
            mimeType="text/plain"
        )
    ]

@app.read_resource()
async def read_resource(uri: str) -> str:
    if uri == "file:///example.txt":
        return "¡Hola desde el Servidor MCP!"
    raise ValueError(f"Recurso desconocido: {uri}")

@app.list_tools()
async def list_tools() -> list[Tool]:
    return [
        Tool(
            name="saludar",
            description="Saludar a alguien por su nombre",
            inputSchema={
                "type": "object",
                "properties": {
                    "nombre": {"type": "string"}
                },
                "required": ["nombre"]
            }
        )
    ]

@app.call_tool()
async def call_tool(name: str, arguments: dict) -> str:
    if name == "saludar":
        return f"¡Hola, {arguments['nombre']}!"
    raise ValueError(f"Herramienta desconocida: {name}")

if __name__ == "__main__":
    asyncio.run(app.run())

Conectando a Claude Desktop

Para usar tu servidor MCP con Claude Desktop, necesitas configurarlo en la configuración de Claude:

Abre la configuración de Claude Desktop
Navega a la sección "Developer"
Agrega la configuración de tu servidor:

{
  "mcpServers": {
    "mi-servidor": {
      "command": "python",
      "args": ["ruta/a/tu/servidor.py"]
    }
  }
}

Reinicia Claude Desktop
Las herramientas y recursos de tu servidor ahora estarán disponibles para Claude

Conectando a VSCode

Para la integración con VSCode, puedes usar la extensión MCP:

Instala la extensión MCP desde el marketplace
Configura tu servidor en .vscode/mcp.json:

{
  "servers": [
    {
      "name": "mi-servidor",
      "command": "python",
      "args": ["ruta/a/tu/servidor.py"]
    }
  ]
}

Casos de Uso del Mundo Real

Aquí hay algunas aplicaciones prácticas para servidores MCP:

Acceso a Bases de Datos

Crea un servidor que permita a Claude consultar tus bases de datos de forma segura:

@app.list_tools()
async def list_tools():
    return [Tool(name="consultar_bd", description="Ejecutar consultas SQL")]

Operaciones del Sistema de Archivos

Construye un servidor que gestione archivos de proyecto:

@app.list_resources()
async def list_resources():
    return [Resource(uri=f"file:///{archivo}") for archivo in os.listdir()]

Integración con APIs

Conecta Claude a APIs externas:

@app.call_tool()
async def call_tool(name, args):
    if name == "obtener_datos":
        response = await http_client.get(args['url'])
        return response.json()

Mejores Prácticas

Seguridad Primero: Siempre valida las entradas y sanitiza las salidas
Manejo de Errores: Proporciona mensajes de error claros
Documentación: Documenta tus herramientas y recursos exhaustivamente
Rendimiento: Usa async/await para operaciones de I/O
Pruebas: Prueba tu servidor con diferentes clientes

Repositorio de Ejemplo

Puedes encontrar un ejemplo completo y funcional en mi repositorio de GitHub:

Repositorio: https://github.com/renzoloyola/MCP-Server

Este repositorio incluye:

Implementación básica del servidor MCP
Ejemplos de configuración para Claude y VSCode
Documentación e instrucciones de configuración
Casos de uso de ejemplo

Conclusión

Construir servidores MCP abre posibilidades infinitas para extender las capacidades de los asistentes de IA. Ya sea que te estés conectando a bases de datos, sistemas de archivos o APIs externas, MCP proporciona una forma estandarizada y poderosa de hacer que tus datos y herramientas sean accesibles para la IA.

El Protocolo de Contexto de Modelo sigue evolucionando, y el ecosistema está creciendo rápidamente. Al crear tus propios servidores MCP, puedes personalizar Claude y otros clientes compatibles para que se ajusten a tus necesidades y flujos de trabajo específicos.

Recursos

¿Has construido un servidor MCP? ¡Comparte tu experiencia en los comentarios!