Stații de lucru

API Security Testing in CI/CD

• Data 10/09/2026
• Autor Costin Dumitru
• 5
• 47

Since you already work with pentesting tools like Burp Suite, Metasploit, and Nikto, think of this as extending that manual mindset into an automated, repeatable pipeline stage. The goal of CI/CD-integrated API security testing is to catch vulnerabilities like broken authorization or injection flaws on every code change, not just during periodic audits.

Testing an API before it reaches production is far cheaper than fixing it after deployment, especially for issues like Broken Object Level Authorization (BOLA) or Broken Function Level Authorization (BFLA), which are the top risks in the OWASP API Security Top 10 2023. The core idea of “shift-left” is simple: generate and lint your OpenAPI specification, run authorization and fuzzing tests automatically, scan infrastructure-as-code for misconfigurations, and fail the build when high-severity issues appear.

Given your background in penetration testing, here’s a question to get you thinking before we go further: when you manually test an API for BOLA today, what steps do you take to confirm one user can’t access another user’s data? Hold that thought, because we’re about to automate exactly that.

CI/CD API security testing generally falls into three buckets, each targeting a different class of OWASP API risks:

• Authentication and authorization tests — verifying BOLA (swap object IDs between two valid users), BFLA (replay admin-only requests with a lower-privilege token), mass assignment (attempt to modify read-only fields via POST/PATCH), and token lifecycle behavior (expired or revoked tokens must return 401, not stale cached data).

• Input and request validation tests — submitting oversized payloads, SQL/NoSQL/command injection strings, path traversal attempts, malformed JSON/XML, and checking that GraphQL endpoints enforce query complexity limits and disable introspection in production.

• Transport and configuration tests — enforcing HTTPS everywhere, validating TLS versions and cipher suites, checking security headers, testing CORS against unauthorized origins, and scanning for verbose debug output that leaks internal paths.

A practical automation pattern for BOLA/BFLA, drawn from real testing workflows, looks like this: extract every route from your OpenAPI spec to build your attack surface list, capture three token sets (admin, standard user, unauthenticated), then programmatically replay the same request while swapping tokens or object IDs between the two user accounts — if a low-privilege token or wrong user’s ID returns a 200 instead of 403/404, you’ve found a flaw.

Building the Pipeline Stage

Rather than treating a security scan as an afterthought, it should run as a pipeline job that blocks deployment on critical findings, similar to how you might already gate deployments on failed unit tests. A minimal GitHub Actions-style stage would download a scanner such as the OWASP API Security Testing Framework, point it at your API with an auth token, output results in a machine-readable format like SARIF, and upload that report to your code scanning dashboard so findings show up alongside pull requests. Tools like OWASP ZAP, Burp Suite (which you already use manually), and 42Crunch can run these scans directly against your OpenAPI/Swagger spec, meaning your existing spec becomes the test target instead of something you write test cases for by hand.

Beyond deployment-triggered scans, it’s worth scheduling separate recurring scans (weekly or monthly) against your live production API, since configuration drift — like a firewall rule change or an expired cert — can introduce vulnerabilities between deployments even without a code change. NIST’s guidance on API protection for cloud-native systems frames this as two complementary layers: static definition-time protections (defining schemas, valid value ranges, and maintaining an API inventory) and runtime protections applied to every request and response, including encryption in transit, authentication/authorization checks, and rate limiting or circuit breaking.

Prioritizing What to Automate First

If you’re setting this up from scratch, the recommended order is: start with authorization testing (BOLA, then BFLA), then authentication, then input validation and rate limiting, then configuration and API inventory checks. A condensed priority view looks like this:

Given your Rocky Linux and Kubernetes experience, you’re well positioned to containerize a scanner like ZAP or the OWASP ASTF as a pipeline job that spins up, hits a staging deployment, and tears down automatically.

To check your understanding: if a CI/CD pipeline scan finds that a standard-user token can successfully call an admin-only /users/delete endpoint, which OWASP risk category does that fall under, and what specific pipeline check would you add to catch it on every future pull request?

Hardening POS/Payment Terminal Integration Networks

• Data 10/09/2026
• Autor Costin Dumitru
• -2
• 36

A payment-terminal network is not just “a VLAN for card machines.” It is a tightly controlled path between the POS/terminal, payment gateway or acquirer, terminal-management system (TMS), and a small set of operational services. The main security objective is to prevent a compromise of a workstation, Wi-Fi network, or back-office server from reaching payment devices or affecting payment traffic. PCI guidance strongly recommends segmentation: without effective isolation, a much broader network can fall into PCI scope.

Before implementing controls, map each payment-data flow: terminal to processor, terminal to TMS, POS to payment middleware, DNS/NTP/DHCP dependencies, logging, monitoring, and vendor-support paths. An asset inventory should identify every point-of-interaction device, its model, serial number, owner, location, firmware, network identity, and support status.

Use separate zones with default-deny controls between them:

• Terminal zone: Dedicated wired switch ports or a dedicated SSID/VLAN for payment terminals only. No corporate laptops, printers, guest devices, or general POS browsing systems.

• Payment services zone: The payment gateway, payment middleware, and/or approved connector. Permit only required terminal-to-service flows.

• Management zone: A hardened TMS, monitoring system, patch repository, and a jump host. It should not be reachable directly from normal administrator workstations.

• Corporate zone: Office users, back-office systems, and standard endpoints. Treat this zone as untrusted relative to the payment environment.

• Internet/processor edge: Allow outbound connections only to documented acquirer, processor, DNS, time, certificate-status, and update destinations.

Segmentation can be physical, logical, or both, but it must stop out-of-scope systems from communicating with—or influencing—the cardholder-data environment. A useful rule is: the terminal may initiate only the precise connections needed to process a transaction and receive authorized management updates; everything else is blocked. 

Avoid broad rules such as “terminal VLAN to Internet: allow.” Replace them with allowlisted flows that have a documented business purpose:

Build policy around both network and identity. For example, a TMS server should be the only system that can manage terminals, and a named, MFA-protected administrator should be the only identity allowed to access that TMS. PCI guidance specifically calls for MFA for access into the cardholder-data environment, including remote access to terminals or terminal-management systems.

Treat the terminal as an embedded security appliance, not as a generic network device.

• Change vendor-default credentials and disable unused local, web, SSH, Telnet, Bluetooth, Wi-Fi, USB, debug, and remote-management interfaces.

• Keep vendor-supported firmware and payment applications current through a controlled, authenticated update path; unsupported terminal software is a serious operational and security risk.

• Enforce certificate validation and modern TLS for terminal-to-processor and terminal-to-TMS communications. Do not accept invalid certificates “to make connectivity work.”

• Use device certificates, mutual TLS, or equivalent strong device identity when supported; IP allowlisting alone is not enough because IP addresses can be spoofed or reassigned.

• Remove sensitive card data from POS logs, error messages, packet captures, databases, and support tickets. Prefer processor tokenization so business systems handle tokens rather than primary account numbers.

• Protect terminals from substitution and tampering: maintain a device inventory, inspect devices regularly, train staff to spot altered equipment, and investigate unexpected reboots, serial-number changes, or new network identities.

Remote vendor support is a high-risk integration path. Never expose a terminal, POS controller, or TMS directly to the public internet. Instead, require an approved remote-access gateway or VPN, MFA, a hardened jump host, time-limited approval, session recording where feasible, and centralized logs. Give vendors a narrowly scoped role: a support account should access only the specified terminal group or TMS function, not your full internal network.

If a payment processor requires a static inbound path, terminate it in a dedicated edge zone and forward only the required protocol to a purpose-built integration component. Do not make a firewall exception from the internet to the terminal VLAN.

Hardening is incomplete until it is tested. Monitor firewall-deny events, new MAC addresses, terminal certificate failures, firmware changes, repeated transaction errors, unusual outbound destinations, TMS admin logins, and configuration drift. Review whether each terminal is communicating only with its allowlisted destinations; a terminal making DNS requests to arbitrary resolvers or HTTPS connections to unfamiliar hosts deserves immediate investigation.

Run segmentation validation from a compromised-user perspective: place a test device in the corporate or guest network and verify it cannot discover, route to, scan, administer, or reach terminal-management interfaces. PCI guidance emphasizes that segmentation should be documented, tested, and maintained—not merely shown as a diagram. Re-test after switch changes, firewall changes, new terminals, processor migrations, TMS upgrades, or vendor remote-access changes.

Fine-Tuning Small language models on Linux

• Data 10/09/2026
• Autor Costin Dumitru
• 2
• 41

Fine-tuning adapts a pretrained model to a narrow task, vocabulary, tone, or response format using your own examples. For a Linux/sysadmin use case, a small language model (SLM) could be adapted to turn Rocky Linux alerts into triage steps, answer internal runbook questions, or classify security-ticket descriptions. The usual efficient approach is supervised fine-tuning (SFT): train on input-output examples so the model learns to predict the desired answer conditioned on the prompt.

Start with a modest model that fits your GPU and a narrow goal. A small, clean dataset usually beats a large, inconsistent one: avoid secrets, access tokens, customer data, passwords, production logs containing identifiers, and unlicensed text. Split the dataset into train, validation, and test sets before training, so you can measure whether the model generalizes rather than merely memorizing examples.

A practical Linux stack is Python in a virtual environment, NVIDIA drivers plus CUDA-compatible PyTorch for GPU training, and the Hugging Face ecosystem: transformers for models, datasets for data, peft for efficient adapters, trl for supervised training, and optionally bitsandbytes for low-bit loading. PEFT methods update a small set of adapter parameters rather than the full model, reducing both compute and storage needs.

Before training, confirm the machine sees the GPU and that PyTorch can use it:

CPU fine-tuning is possible for very small models, but it is generally slow. On a single consumer NVIDIA GPU, 4-bit quantization plus LoRA is often the practical route: loading weights in 4-bit or 8-bit precision saves memory, while the adapter remains trainable.

Prepare the Dataset

For chat-oriented tuning, use JSON Lines, with one valid JSON object per line. Keep the prompt explicit and make answer style consistent:

Create three files: train.jsonl, validation.jsonl, and test.jsonl. Validation data guides training decisions; test data stays untouched until the end. Include both normal and adversarial cases relevant to the deployment: ambiguous requests, requests for unavailable information, commands with unsafe consequences, and examples where the correct answer is to ask for context instead of guessing.

LoRA (Low-Rank Adaptation) freezes the base model and trains small adapter matrices attached to selected model layers. The result is a compact adapter rather than a full duplicate of the model; PEFT’s documented workflow is to load the base model, define LoraConfig, wrap it as a trainable PEFT model, and train normally.

For an SLM, target the attention projection layers commonly named q_proj and v_proj; verify your particular architecture first because module names vary. Key settings are:

• r — adapter rank. Start around 8 or 16; a larger rank can learn more but costs more VRAM.

• lora_alpha — scaling factor. A common starting relationship is approximately two times r.

• lora_dropout — regularization. Start around 0.05 for smaller datasets.

• learning_rate — start conservatively, such as 1e-4 to 2e-4 for LoRA SFT.

• max_seq_length — cap it to the real task need; longer sequences consume much more memory.

Minimal Training Script

Save the following as train.py. Replace YOUR_BASE_MODEL with a model you are licensed and authorized to use, and inspect its model card for its expected prompt format and intended use.

TRL’s SFTTrainer is built specifically to simplify supervised fine-tuning, and when given a PEFT configuration it initializes the adapter training path for you. If bf16=True fails on your GPU, use fp16=True instead; do not enable both.

Do not judge success only by a declining training loss. Compare the base model and tuned model against the held-out test set, then manually probe realistic requests. For an internal Linux assistant, assess command correctness, whether prerequisites are stated, whether destructive commands are guarded, whether outputs are invented, and whether the model declines to fabricate environment-specific facts.

Watch for these common failures:

• Overfitting: Training loss drops while validation loss rises. Reduce epochs, lower rank, improve dataset variety, or add examples.

• Bad formatting: The model’s response template differs from your training format. Match the base model’s chat template during data preparation and inference.

• Catastrophic behavior change: A narrow dataset makes the model repetitive or overly confident. Mix high-quality general instruction examples with your specialist examples.

• Out-of-memory errors: Lower max_seq_length, batch size, LoRA rank, or use gradient accumulation and 4-bit loading.

• Unsafe operational output: Add counterexamples that require warnings, confirmation, backup advice, or requests for logs before recommending a risky command.

A LoRA output normally contains adapter weights and configuration, not a standalone base model. At inference time, load the original base model and then attach the adapter; PEFT supports saving adapters and loading them on the correct base model through the adapter configuration. This makes versioning practical: store a model manifest containing the base-model revision, adapter version, dataset version/hash, training parameters, evaluation result, owner, and approval status.

For your Linux-first workflow, package inference in a container, run it with a non-root user, mount model data read-only, avoid embedding access tokens in images, restrict egress if the model does not need external access, and expose the API only behind authentication and rate limits. Keep model artifacts separate from training data, especially if the data originated from internal tickets or infrastructure documentation.

Automating PostgreSQL/MongoDB Backups in Kubernetes

• Data 10/09/2026
• Autor Costin Dumitru
• 3
• 43

A Kubernetes backup system must protect three things: database data, database-level metadata, and the restore process itself. A scheduled backup that has never been restored is only an assumption, so design the workflow around a measurable recovery point objective (RPO) and recovery time objective (RTO).

A robust pattern is:

1. A Kubernetes CronJob starts a short-lived, non-root backup Pod.

2. The Pod reads credentials from a Secret mounted as environment variables or files.

3. It connects to PostgreSQL or MongoDB through an internal Service using least-privilege backup credentials.

4. It creates a compressed, encrypted backup artifact.

5. It uploads the artifact to object storage or a remote backup repository.

6. It writes logs, emits metrics, and removes temporary local files.

7. A separate scheduled restore test validates the latest backup in an isolated namespace.

Do not depend only on a PersistentVolume mounted beside the database. If the cluster, storage class, credentials, or namespace are compromised together, both the production data and “backup” may be lost.

PostgreSQL Backup Strategy

For logical backups, pg_dump backs up one PostgreSQL database, while pg_dumpall covers an entire cluster and preserves global objects such as roles and tablespaces. For individual application databases, use the custom archive format (-Fc): it is compressed, works with pg_restore, and supports selective restore operations.

A basic PostgreSQL backup command is:

The --no-owner option helps when restoring into a different environment where source role names do not exist. If your recovery requires roles and tablespaces too, run a separate global metadata export:

For large, high-change PostgreSQL systems, logical dumps may not meet your RPO/RTO. Use physical backups plus WAL archiving through a PostgreSQL-aware solution such as pgBackRest, WAL-G, or an operator-supported backup mechanism. The important distinction is that pg_dump captures a logical snapshot, while point-in-time recovery requires archived WAL files in addition to a suitable base backup.

For self-managed MongoDB, mongodump creates a binary export and mongorestore restores that export to a running MongoDB deployment. Use a single compressed archive for easier handling and avoid a large tree of loose BSON files:

mongodump can back up a full deployment, a database, a collection, or query-filtered content, depending on options and operational needs. For a replica set, ensure you understand consistency requirements and test restoration against the exact MongoDB topology you operate. For managed MongoDB Atlas, platform-native continuous backups and point-in-time recovery are often preferable to running mongodump as the sole protection mechanism.

This example uses PostgreSQL. The same container pattern works for MongoDB by replacing the image and backup command. It writes to /work; in production, add an upload command to S3-compatible storage, Azure Blob, GCS, or a hardened backup server.

concurrencyPolicy: Forbid prevents a slow backup from overlapping with the next scheduled run. Set startingDeadlineSeconds so an overdue backup does not start at an operationally unsafe time. CronJobs are appropriate for recurring work, but Kubernetes documents that scheduling can be approximate, so make the job idempotent and record success externally rather than trusting schedule timing alone.

Use a dedicated database account whose permissions are sufficient to read backup data but not to modify production records. Store connection strings, passwords, TLS certificates, and object-storage credentials in a secret-management system; restrict access with namespace RBAC, separate service accounts, and cloud workload identity where available.

Apply these controls:

• Use TLS for database connections and object-storage uploads.

• Encrypt backup files before leaving the Pod, or use a destination that provides strong server-side encryption with independently controlled keys.

• Keep backup storage in a separate account, project, or tenant from the production Kubernetes cluster.

• Enable versioning and retention locks/object immutability to resist accidental deletion and ransomware.

• Include a checksum or manifest containing backup timestamp, database/version, artifact size, checksum, and tool version.

• Never place database URIs, passwords, or cloud keys directly in CronJob YAML, Git repositories, or CI logs.

• Restrict egress from the backup Pod to only the database endpoint, DNS/time dependencies, and the backup destination.

Retention, Monitoring, and Restores

Define retention before automation. A typical scheme might keep daily backups for 14–30 days, weekly backups for several months, and monthly backups for a year, but the right policy follows business, legal, and storage requirements. Monitor at least: last-success timestamp, job duration, output size, upload success, checksum verification, and age of the newest restorable artifact.

Restore testing should be automated in a disposable namespace: provision an empty Postgres or MongoDB instance, download a recent backup, restore it, run integrity checks and representative application queries, then destroy the environment. PostgreSQL custom-format dumps restore with pg_restore; MongoDB archive dumps restore with mongorestore. A successful restore test is the most meaningful backup metric.mongodb+1

As a practical first step, define whether your most important database needs daily logical recovery or point-in-time recovery, then explain what maximum acceptable data loss in minutes or hours would be for that workload.