Security

User Entity Behavior Analysis (UEBA) is a security layer that uses machine learning and analytics to detect threats by analyzing patterns in user and entity behavior. Here’s an oversimplified example of UEBA: suppose you live in Chicago. You’ve lived there for several years and rarely travel. But suddenly there’s a charge to your credit card from a restaurant in Italy. Someone is using your card to pay for their lasagna! Luckily, your credit card company recognizes the behavior as suspicious, flags the transaction, and stops it from settling. This is easy for your credit card company to flag: they have plenty of historical information on your habits and have created a set of logical rules and analytics for when to flag your transactions. But most threats are not this easy to detect. Attackers are continuously becoming more sophisticated and learning to work around established rules. As a result, traditional UEBA that relies primarily on static, rigid rules is no longer enough to protect your systems. The End of Traditional UEBA — or, Why Your UEBA No Longer Works Many UEBA tools were built around static rules and predefined behavioral thresholds. Those approaches were useful for catching predictable, well-understood behavior patterns, but are not great in modern environments where user activity, applications, and attacker behavior change constantly. Soon, AI agents will act on behalf of users and introduce even more diversity. Here are the main limitations of traditional, static-rule-driven UEBA: Static behavioral thresholds don’t adapt to real user behavior over time. They rely on fixed assumptions (e.g., “alert if X happens more than Y times”), which quickly become outdated as user behavior and environments evolve.Rules require continuous manual tuning. Security teams spend time chasing false positives or rewriting rules as user behavior changes, which slows response and increases operational overhead.Isolated detection logic lacks context. Legacy UEBA often analyzes events in silos, instead of correlating activity across identity, endpoint, network, and application layers. This limits the ability to detect subtle behavioral anomalies. As a result, certain types of threats that blend into normal activity can go unnoticed despite the presence of rules. So if legacy UEBA is not effective …what’s the solution? What Modern Enterprises Actually Need from UEBA Modern enterprises need UEBA systems that can do three things: Immediately detect attacks. When attackers can morph in an instant, you need a security layer that moves just as fast.Recognize attacks that are highly sophisticated and complex. Attacks are no longer simple enough to be caught by a set of rules  —  even advanced ones backed with behavioral analytics.Integrate seamlessly with existing security operations. Let’s look at each in more detail and how it can be achieved. Immediately Detect Attacks (Without a Long Training Period) Traditional UEBA training periods leave organizations vulnerable for months and chronically behind on detecting the latest threats. A typical three to six-month learning period creates a huge security gap. Day-one detection capabilities for behavioral threats and compromised accounts require first-seen and outlier rules that can spot anomalous behavior immediately without waiting for machine learning models to mature. You need near-instant behavioral baselines. How? Luckily, most organizations already have the data they need: years of historical log information sitting in their security information and event management (SIEM) systems. Modern UEBA systems use this information to create behavioral baselines instantly. For example, companies that advocate for the “log everything” approach have tools that use the data you already have to create powerful baselines in just minutes. Detect Highly Sophisticated Attacks Today’s attacks blend in with normal business operations. Correlation rules miss behavioral threats that show only subtle anomalies; they can’t identify compromised accounts or insider threats that are performing normal-looking activities. Modern UEBA solutions must be able to detect first-seen activities, such as unusual file sharing via OneDrive. They need to gain access to new proxy categories and suspicious cloud service usage that don’t match historical user behavior. This comes down to using the right tools. For example, Microsoft Sentinel can identify unusual Azure identity behaviors such as abnormal cloud service access patterns that could indicate account compromise or data exfiltration. And Sumo Logic has first-seen and outlier rules that can detect when an attacker is trying to use a network sniffing tool. They catch endpoint enumeration and suspicious email forwarding rules that deviate from established patterns. Integration With Existing Security Operations UEBA delivers meaningful value when it fits naturally into existing security workflows. Security teams rely on SIEM, SOAR, identity systems, and endpoint tools to build a complete picture of activity across their environment. UEBA works best when its behavioral insights are delivered in the same place analysts already investigate and respond to alerts. Effective UEBA solutions, therefore, integrate directly with the broader security platform, allowing behavioral anomalies to be correlated with logs, identity events, and threat intelligence. This unified context helps analysts make faster, more accurate decisions without switching tools or managing separate consoles. Flexibility is also important. Organizations must be able to adjust detection logic and behavioral thresholds to match their environment, risk tolerance, and operational needs. When UEBA is tightly integrated and adaptable, it becomes an extension of the security workflow rather than an additional system to maintain. UEBA as the Foundation for AI Security Agents UEBA hasn’t been replaced by AI. Instead, UEBA has become the way to train AI. AI-powered detection and response solutions perform best when they ingest clean, comprehensive behavior baselines, and that’s exactly what mature UEBA can provide. AI Agents Need Quality Behavioral Baselines AI security agents aren’t magic. They follow the GIGO (garbage in, garbage out) principle just like any other data-intensive system. Feed an AI agent high-quality behavioral data, and it will thrive. But if you feed it insufficient or poor-quality data, then you’ll become part of the 95% statistic of AI pilots that fail to deliver real business value. Structured UEBA rules also give the agents specialist knowledge, such as who should log in where, how often a service account connects to S3, and typical overnight file volumes. AI agents can learn (and extend) these rulesets. AI Detects, Then AI Responds Security teams often drown in alerts. Teams can’t keep up. But when UEBA feeds AI: First-seen rules become automatic triggers. Instead of waiting for an analyst, an agent can begin gathering data and context within seconds.AI can rank threats, helping to make sure human attention is given to the events with the biggest deviation or highest blast radius.Entity relationship maps derived from UEBA help agents model lateral-movement risk and choose containment tactics (for example: quarantine the host, revoke credentials, etc.). Once the system can reliably detect threats, you can take it to the next level and allow your AI agents to take action, too. From UEBA Rules to Autonomous Security Operations Manual security operations have a scaling problem. They can’t keep pace with modern threat volumes and complexity. As a result, organizations miss threats or burn out security analysts with overwhelming alert fatigue. But with UEBA first-seen rules, AI agents can immediately begin collecting evidence and correlating events when anomalous behavior is detected. Outlier detection can feed AI-driven risk scoring and prioritization algorithms. And behavioral baselines can ensure that automated responses are based on a solid understanding of what constitutes legitimate versus suspicious activity within the specific organizational context. You can still have a human in the loop, authorizing each action recommended by the AI system. Eventually, you may delegate action to the AI system as well, with humans merely being notified after the fact. Building AI-Ready Behavioral Foundations Now Modern UEBA platforms are already generating AI-compatible behavioral data. These platforms structure their outputs in ways that AI agents can easily consume and act upon. For example: Ongoing discovery of the best ways to format and organize data to fit optimally into the context of LLMs, and how to provide them with effective toolsSignal-clustering algorithms to reduce the noise that might confuse an AI agent’s decision-making. This ensures that only meaningful behavioral anomalies reach automated systems for action.Rule customization and match lists provide structured data that AI agents can interpret and act upon. This creates clear decision trees for autonomous responses.Historical baseline capabilities create rich training datasets without waiting months for AI deployment. Organizations can leverage years of existing log data. AI agents can begin operating with sophisticated behavioral understanding from day one rather than starting with blank behavioral models. With these capabilities already in place, organizations can transition seamlessly from manual to automated security operations. The Bottom Line When implementing UEBA, focus on true principles and actionable strategies: 1. Ensure comprehensive, high‑quality data integration. Use all relevant data sources: existing logs, new telemetry, identity systems, endpoints, and cloud apps to build complete behavioral profiles. If critical data is missing, you should collect it and add it to the UEBA’s scope. For example, a user’s calendar showing a business trip to Tokyo is very relevant when the system detects login attempts from Japan. 2. Accelerate meaningful baselines using historical data and rapid observation periods. Leverage historical log data to establish baselines quickly, but expect this to take a couple of days to a few weeks. Supplement with fresh data as needed to ensure the baseline reflects current behaviors. For example, if an employee moves to a different team, the system should expect a change in behavior. 3. Integrate UEBA insights with your current security workflows. UEBA should capitalize on SIEM and other security tools to deliver high-impact alerts and operational value. Avoid requiring extensive new infrastructure unless necessary, and always align the solution to your organization’s needs. These approaches deliver immediate value and adapt to changes to maximize the coverage and accuracy of behavioral analytics. Your success metrics matter just as much as your implementation. Track the following: How many sophisticated threats does UEBA catch that your traditional systems missThe reduction in dwell time for compromised accountsCoverage improvements for lateral movement and unknown attack patternsAnalyst efficiency gains from richer contextual alerts. These metrics prove value to stakeholders and help you continuously refine your approach. While classic rule-based UEBA relied on manual configuration, today’s UEBA platforms enhance these foundations with autonomous analytics using statistical models, adaptive baselines, and AI-driven outlier detection. Functions like first-seen and outlier detection do leverage rules, but they operate as part of a dynamic, context-aware system rather than a set of static match expressions. AI agents continuously monitor and analyze vast streams of behavioral data, learning what constitutes normal activity and identifying subtle anomalies that may indicate emerging threats. By correlating signals across users, devices, and time, these agents enable real-time, adaptive detection and response. This elevates security operations from manually maintained static rule matching to intelligent and proactive protection.

By Alvin Lee CORE

In an increasingly globally connected world, nonprofit organizations are as much at risk and vulnerable to cyber threats as large multinational corporations, if not more so. To keep cyber threats at bay, traditional security models have often relied on devices such as firewalls, virtual private networks (VPNs), and similar tools, often based on the underlying assumption that anyone inside the network is trusted by default. Zero Trust Architecture (ZTA) is based on the concept that nothing is trusted by default, whether it is an internal or external stakeholder. The model offers a fundamentally different approach: never trust, always verify. This approach is particularly critical, as nonprofits often handle sensitive donor information, volunteer and beneficiary data, and other confidential information that must always remain secure. Why Nonprofits Are Attractive Targets Even though nonprofits might have limited budgets, they are still attractive targets for cybercriminals, often because they hold a wealth of sensitive and valuable information. High-value assets that can be exploited include donor databases, payment records, and personally identifiable information (PII) of beneficiaries. Additionally, nonprofits that rely on volunteers, contractors, or third-party partners can also be at risk if their access controls are weak. These high-value assets can be exploited for financial gain, identity theft, or ransomware attacks. Once a cyberattack occurs, there can be an erosion of donor trust, with regulatory penalties potentially applied if data breaches occur. Core Components of Zero Trust The underlying principle of Zero Trust Architecture is that no user, device, or system should be implicitly trusted, whether inside or outside the network. Key components include: Identity and Access Management (IAM): Ensures that only authenticated and authorized users can access specific resources, often strengthened through multi-factor authentication (MFA) and role-based controls.Device Security: Validates the health of devices before granting access.Least Privilege Access: Restricts users to only the data or tools required for their role.Network Segmentation: Creates gaps between networks to minimize the impact of breaches.Continuous Monitoring: Provides real-time visibility on an ongoing basis. Sensitive data across all stages — at rest, in transit, and in motion — must always be protected. This forms the basis for adhering to the confidentiality pillar of the CIA Triad. Protecting Donor and Beneficiary Data Nonprofits must strictly protect donor and beneficiary data. Donors share personal information, and beneficiaries may provide confidential information about themselves. IT system disruptions can halt fundraising operations. Additionally, nonprofits must comply with multiple regulations, and breaches could result in severe penalties and long-term reputational damage. Such incidents undermine credibility, making it harder to attract donors, grants, and partnerships. Identity and Access Management (IAM) Nonprofits often deal with a broad array of stakeholders, including employees, staff, third-party contractors, and external partners. A robust IAM strategy is critical in these environments. IAM ensures that only the right individuals have appropriate access to the right resources at the right time. Different levels of access can be managed via granular IAM policies. Additionally, IAM enhances operational efficiency. Access controls, such as role-based access and time-limited credentials, help prevent data exposure. Enabling Safe Field and Remote Operations Nonprofits face unique challenges operating in distributed environments, either remotely or in the field. The primary risk in these situations is unauthorized access. Field staff may require access to confidential information through personal devices or public WiFi. Natural disasters or pandemics can also disrupt operations, preventing staff from accessing central offices. These issues can often be resolved by using cloud-based systems, ensuring uninterrupted service delivery while maintaining security. Conclusion – Roadmap for Nonprofits to Adopt Zero Trust Secure systems are not optional for nonprofits; they are an integral part of a mission-driven strategy. The first step is to perform an overall security posture assessment, which is crucial for identifying critical systems, assets, and the right individuals to safeguard them. Next, nonprofits must implement robust IAM strategies as discussed above. The third stage is protecting devices and endpoints. Finally, data protection and application security are critical tasks. These activities can be implemented incrementally, with access controls and hardening strategies strengthened based on the organization’s overall maturity. A Zero Trust strategy acts not just as an enabler but as the foundational framework on which a nonprofit’s entire cybersecurity strategy rests.

The Edge Observability Security Challenge Deploying an open-source observability solution to distributed retail edge locations creates a fundamental security challenge. With thousands of locations processing sensitive data like payments and customers' personally identifiable information (PII), every telemetry component running on the edge becomes a potential entry point for attackers. Edge environments operate in spaces where there is limited physical security, bandwidth constraints shared with business-critical application traffic, and no technical staff on-site for incident response. Therefore, traditional centralized monitoring security models do not fit in these conditions because they require abundant resources, dedicated security teams, and controlled physical environments. None of them exists on the edge. This article explores how to secure an OpenTelemetry (OTel) based observability framework from the Cloud Native Computing Foundation (CNCF). It covers metrics, distributed tracing, and logging through Fluent Bit and Fluentd. Securing OTel Metrics Mutual Transport Layer Security (TLS) Security of metrics is enabled through mutual TLS (mTLS) authentication, where both client and server end need to prove their identity using certificates before communication can be established. This ensures trusted communication between the systems. Unlike traditional Prometheus deployments that expose unauthenticated HTTP stands for Hypertext Transfer Protocol (HTTP) endpoints for every service, OTel's push model allows us to require mTLS for all connections to the collector (see Figure 1). Figure 1: Multi-stage security through PII removal, mTLS communication, and 95% volume reduction Security configuration, otel-config.yaml YAML receivers: otlp: protocols: grpc: endpoint: mysite.local:55690 tls: cert_file: server.crt key_file: server.key otlp/mtls: protocols: grpc: endpoint: mysite.local:55690 tls: client_ca_file: client.pem cert_file: server.crt key_file: server.key exporters: otlp: endpoint: myserver.local:55690 tls: ca_file: ca.crt cert_file: client.crt key_file: client-tss2.key Multi-Stage PII Removal for Metrics Metrics often end up capturing sensitive data by accident through labels and attributes. A customer identity (ID) in a label, or a credit card number in a database query attribute, can turn compliant metrics into a regulatory violation. The implementation of multi-stage PII removal fixes this problem in depth at the data level. Stage 1: Application-level filtering. The first stage happens at the application level, where developers use OTel Software Development Kit (SDK) instrumentation that hashes out user identifiers with the SHA-256 algorithm before creating metrics. Uniform Resource Locators (URLs) are scanned to remove query parameters like tokens and session IDs before they become span attributes. Stage 2: Collector-level processing. The second stage occurs in the OTel Collector's attribute processor. It implements three patterns: complete deletion for high-risk PII, one-way hashing for identifiers using SHA-256 with a cryptographic salt and use regex to clean up complex data. Stage 3: Backend-level scanning. The third stage provides backend-level scanning where centralized systems perform data loss prevention (DLP) scanning to detect any PII that reached storage, triggering alerts for immediate remediation. When the backend scanner detects PII, it generates an alert indicating the edge filters need updating, creating a feedback loop that continuously improves protection. Aggressive Metric Filtering Security is not only about encryption and authentication, but also about removing unnecessary data. Transmitting less data reduces the attack surface, minimizes exposure windows, and makes anomaly detection easier. There may be hundreds of metrics available out of the box, but filtering and forwarding only the needed metrics reduces up to 95% of metric volume. It saves resources, network bandwidth utilization, and management bottlenecks. Resource Limits as Security Controls The OTel Collector sets strict resource limits that prevent denial-of-service attacks. resourceLimitProtection against Memory 500MB hard cap Out-of-memory attacks Rate limiting 1,000 spans/sec/service Telemetry flooding attacks Connections 100 concurrent streams Connection exhaustion These limits ensure that even when an attack happens, the collector maintains stable operation and continues to collect required telemetry from applications. Distributed Tracing Security Trace Context Propagation Without PII Security for distributed traces can be enabled through the W3C Trace Context standard, which provides secure propagation without exposing sensitive data. The traceparent header can contain only a trace ID and span ID. No business data, user identifiers, or secrets are allowed (see Figure 1). Critical Rule Often Violated Never put PII in baggage. Baggage is transmitted in HTTP headers across every service hop, creating multiple exposure opportunities through network monitoring, log files, and services that accidentally log baggage. Span Attribute Cleaning at Source Span attributes must be cleaned before span creation because they are immutable once created. Common mistakes that expose PII include capturing full URLs with authentication tokens in query parameters, adding database queries containing customer names or account numbers, capturing HTTP headers with cookies or authorization tokens, and logging error messages with sensitive data that users submitted. Implementing filter logic at the application level removes or hashes sensitive data before spans are created. Security-Aware Sampling Strategy Reduction of 90% normal operation traces is supported by the General Data Protection Regulation (GDPR) principle of data minimization while maintaining 100% visibility for security-relevant events. The following sampling approach serves both performance and security by intelligently deciding which traces to keep based on their value. trace typesample raterationale Error spans 100% Potential security incidents require full investigation High-value transactions 100% Fraud detection and compliance requirements Authentication/authorization 100% Security-critical paths need complete visibility Normal operations 10-20% Maintains statistical validity while minimizing data collection Logging Security With Fluent Bit and Fluentd Real-Time PII Masking Application logs are the highest risk involved data, which contain unstructured text that may include anything developers print. Real-time masking of PII data before logs leave the pod represents the most critical security control in the entire observability stack. The scanning and masking happen in microseconds, adding minimal overhead to log processing. If developers accidentally log sensitive data, it's caught before network transmission (see Figure 2). Figure 2: Logging security enabled through two-stage DLP, Real-Time Masking in microseconds, TLS 1.2+ End-to-End, Rate Limiting, and Zero Log-Based PII Leaks Security configuration, fluent-bit.conf YAML pipeline: inputs: - name: http port: 9999 tls: on tls.verify: off tls.cert_file: self_signed.crt tls.key_file: self_signed.key outputs: - name: forward match: '*' host: x.x.x.x port: 24224 tls: on tls.verify: off tls.ca_file: '/etc/certs/fluent.crt' tls.vhost: 'fluent.example.com' Fluentd.conf <transport tls> cert_path /root/cert.crt private_key_path /root/cert.key client_cert_auth true ca_cert_path /root/ca.crt </transport> Secondary DLP Layer Fluentd provides secondary DLP scanning with different regex patterns designed to catch what Fluent Bit missed. This includes private keys, new PII patterns, sensitive data, and context-based detection. Encryption and Authentication for Log Transit Transmission of logs is secured through TLS 1.2 or higher encryption method using mutual authentication. In this communication method, Fluent Bit authenticates to Fluentd using certificates, and Fluentd authenticates to Splunk using tokens. This approach prevents network attacks that could capture logs in transit, man-in-the-middle attacks that could modify logs, and unauthorized log injection. Rate Limiting as Attack Prevention Preventing log flooding avoids both performance and security issues. An attacker generating massive volume of logs can hide malicious activity in noise, consume all disk space causing denial of service, overwhelm centralized log systems, or increase cloud costs until logging is disabled to save money. Rate limiting at 10,000 logs per minute per namespace prevents these attacks. Security Comparison: Three Telemetry Types AspectMetrics (Otel)Traces (Otel)Logs (Fluent bit/fluentd) Primary Risk PII in labels/attributes PII in span attributes/baggage Unstructured text with any PII Authentication mTLS with 30-day cert rotation mTLS for trace export TLS 1.2+ with mutual auth PII Removal 3-stage: App --> Collector --> Backend 2-stage: App --> Backend DLP 3-stage: Fluent Bit --> Fluentd --> Backend Data Minimization 95% volume reduction via filtering 80-90% via smart sampling Rate limiting + filtering Attack Prevention Resource limits (memory, rate, connections) Immutable spans + sampling Rate limiting + buffer encryption Compliance Feature Allowlist-based metric forwarding 100% sampling for security events Real-time regex-based masking Key Control Attribute processor in collector Cleaning before span creation Lua scripts in sidecar Key Outcomes Secured open-source observability across distributed retail edge locationsAchieved Full Payment Card Industry (PCI) Data Security Standard (DSS) and GDPR compliance Reduced bandwidth consumption by 96% Minimized attack surface while maintaining complete visibility Conclusion Securing a Cloud Native Computing Foundation-based observability framework at the retail edge is both achievable and essential. By implementing comprehensive security across OTel metrics, distributed tracing, and Fluent Bit/Fluentd logging, organizations can achieve zero security incidents while maintaining complete visibility across distributed locations.

AI has long progressed past statistical models that generate forecasts or probabilities. The next generation of AI systems is agents, autonomous cloud-native systems capable of acting and intervening in an environment without human intervention or approval. Agents can provision infrastructure, reroute workloads, or optimize costs. They can also remediate incidents or apply other autonomous transformations at scale in cloud-native systems. Autonomy is particularly powerful in cloud-native ecosystems: think of self-tuning Kubernetes clusters, self-adapting CI/CD pipelines that dynamically route riskier code to human gatekeepers, or self-orchestrating serverless functions that maintain performance SLAs under previously unseen load spikes. But with autonomy comes a great responsibility: giving an AI agent the power to act in the cloud-native environment changes the nature of the threat surface in a fundamental way. In this article, we’ll cover security and architecture patterns that enable organizations to safely build and consume agentic AI in cloud-native systems so they can innovate confidently without losing control. The New Frontier: Agentic AI Traditional cloud-based AI systems are by nature bounded: the AI system processes data and provides an output (a forecast, classification, or recommendation), which is then consumed by a human or an API. Agents, in contrast, are AI systems that cross a fundamental threshold. They must have: Computational power – reasoning over complex real-time signals (ML models, orchestration state, business risk models)Actionability – credentials, APIs, or other hooks to actually execute those decisions In cloud-native environments, agentic AI could look like: Auto-scaling microservices is not just based on CPU utilization thresholds, but also on social media sentiment analysis or predicted spikes in demandIntelligent incident remediation bots that proactively patch vulnerable containers, spin up new database replicas, or quarantine containers without manual ticket escalationCost optimization agents that continuously reconfigure microservice workloads and architectures for optimal cost/latency tradeoffs In each case, the agent has the power to “drive the car” autonomously in the cloud-native environment. But this also means that the agent is a first-class citizen in the threat model. The Expanded Threat Model: AI Agents In addition to traditional concerns about human or API misuse, or inadvertent bugs in the agent logic, there are a number of new attack vectors that are opened up when AI agents are introduced in a system: Credential abuse: Any API tokens, service accounts, or other credentials in the agent’s control are also potentially attacker-controlled if compromised.Autonomous escalation: The agent’s permissions might slowly creep up (intentionally or otherwise), e.g., to resolve an incident, it first escalates its own access rights to resolve the incident and then reduces them, creating the ability to later repeat this behavior.Self-replicating exploits: Bad prompts, poisoning of the training data, or other compromises to the agent decision logic can create highly repeatable automated attacks that are difficult to remediate.Opaque autonomy: The reasoning process of the agent is non-deterministic (unlike script automation), leading to challenges in monitoring, compliance, and auditing the actions taken by agents. Simply put, autonomy = risk amplification. The right architecture has to predict and mitigate potential failure modes before an agent is deployed. Patterns for Safe Autonomy in Cloud-Native Systems To safely consume or build agentic AI in cloud-native systems, organizations need to adopt patterns and practices that put an emphasis on architectural controls, accountability, and resilience. This results in a number of common patterns that enable autonomous agents while managing the new risks. 1. Policy-as-Code Boundaries AI agents must never have a free-form relationship with the runtime environment. Policy boundaries (preferably as code) should be enforced: Define boundaries of acceptable action (e.g., restart containers but not delete entire clusters).Use Kubernetes native Open Policy Agent (OPA) or Kyverno to enforce the constraints in real time.Combine policy-as-code with “deny by default” (agents must explicitly justify every action they want to perform). Benefit: Predictability and low blast radius 2. Sandboxed Execution Agents should not execute directly in production environments, or with unrestricted privileges: Deploy agents in dedicated namespaces, pods, or serverless sandboxes.Use time-bound, scoped credentials via IAM or workload identity federation.Route agent’s actions through human-readable approval APIs (middlewares or proxies) between the agent and production systems. Benefit: Containment — if an agent misbehaves, the damage is limited 3. Event-Driven Autonomy Instead of continuous, open-ended control, restrict agents to an event-driven model: Agents can only change the state of a system in response to approved events (e.g., scale services when a traffic spike is detected).Event bus (Kafka, EventBridge, NATS, or similar) for increased auditability of agent actions.Agents take a discrete number of clearly observable actions in this way. Benefit: Action auditing and reversibility of AI actions 4. Explainability and Audit Logging Opaque decision-making is not acceptable in regulated industries or scenarios: Require explainable AI (Explainable Reasoning) for every action taken by agents.Store all agent-initiated events/logs in immutable action logs.Integrate with Security Information and Event Management (SIEM) or Security Orchestration, Automation, and Response (SOAR) tools for anomaly detection. Benefit: Accountability and forensic visibility 5. Resilient Fail-Safes Agents will make mistakes. Architecture must incorporate the assumption of failure: Critical actions (e.g., turn off a production database cluster) should be limited to require a human co-signatureRollback/override of agent-led processesAI agent health monitoring and auto-quarantine on anomalous activity Benefit: Resilience to both malicious and inadvertent failures Agentic AI in the Cloud: Developer Checklist When either building or consuming agentic AI in cloud-native systems, there are a number of questions every engineer or architect should be asking: Identity and access: Does the agent have long-lived permissions or enforce least-privilege/scoped credentials with expiration dates?Boundaries: Are the policy boundaries the agent operates within codified, enforced, and verified?Observability: Is there full auditability and traceability of all actions back to agent reasoning?Containment: Is the agent adequately sandboxed, or is its blast radius too large?Recovery: Is there the ability to roll back agent decisions or perform an override in real-time? Case Study: Autonomous Cloud Cost Optimization As an example, consider an AI agent that autonomously optimizes cloud costs. Without the following controls, the agent might abruptly deallocate critical resources or production clusters, causing system outages. With a policy-as-code control, the agent’s permissible actions are restricted (e.g., to non-production environments)With a sandboxed execution control, the agent’s actions are limited via a validation proxy between the agent and productionWith event-driven autonomy, the agent only has the ability to take action when validated events or schedules are met.With explainable autonomy, the agent must generate a cost-benefit report before it can take action. Result: An agent with autonomous power is tightly bound and effectively auditable. The Future: Autonomous Operators and Resilience Moving forward, agentic AI will mature from assistants (AI systems that provide analysis and guidance) to become autonomous operators that have the ability to self-heal: Kubernetes that automatically rebalances workloads and clusters without human interventionService mesh controllers that negotiate service-level objectives dynamically between microservicesCloud-native security agents that automatically quarantine suspicious microservices in real time The goal is ultimately to create resilience-first autonomous agents that strengthen rather than erode trust in cloud-native systems. Conclusion Agentic AI is the natural next phase of cloud-native systems: from passive data analysis to active, autonomous intervention in the cloud-native environment. However, autonomy unbounded by a principled architecture is a recipe for disaster. Policy guardrails, sandboxed execution, event-driven autonomy, explainable autonomy, and resilient fail-safes are all necessary architectural controls to allow AI agents to be safely embedded in cloud-native environments. In the cloud-native world, the most successful systems will be both autonomously secure and automated.

In a world where attackers routinely scan public repositories for leaked credentials, secrets in source code represent a high-value target. But even with the growth of secret detection tools, many valid secrets still go unnoticed. It’s not because the secrets are hidden, but because the detection rules are too narrow or overcorrect in an attempt to avoid false positives. This creates a trade-off between wasting development time investigating false signals and risking a compromised account. This article highlights research that uncovered hundreds of valid secrets from various third-party services publicly leaked on GitHub. Responsible disclosure of the specific findings is important, but the broader learnings include which types of secrets are common, the patterns in their formatting that cause them to be missed, and how scanners work so that their failure points can be improved. Further, for platforms that are accessed with secrets, there are actionable improvements that can better protect developer communities. What Are “Secrets” in Source Code? When we say “secrets,” we’re not only talking about API tokens. Secrets include any sensitive value that, if exposed, could lead to unauthorized access, account compromise, or data leakage. This includes: API Keys: Tokens issued by services like OpenAI, GitHub, Stripe, or Gemini.Cloud Credentials: Access keys for managing AWS cloud resources or infrastructure.JWT Signing Keys: Secrets used to sign or verify JSON Web Tokens, often used in authentication logic.Session Tokens or OAuth Tokens: Temporary credentials for session continuity or authorization.One-Time Use Tokens: Password reset tokens, email verification codes, or webhook secrets.Sensitive User Data: Passwords or user attributes included in authentication payloads. Secrets can be hardcoded, generated dynamically, or embedded in token structures like JWTs. Regardless of the specific form, the goal is always to keep them out of source control management systems. How Secret Scanners Work Secret scanners generally detect secrets using patterns. For example, a GitHub Personal Access Token (PAT) like: JavaScript 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n might be matched by a regex rule such as: JavaScript ghp_[A-Za-z0-9]{36} To reduce false positives that string literal matching alone might flag, scanners often rely on: Validation: Once a match is found, some tools will try to validate the secret is in fact a secret and not a placeholder example. This can be done by contacting its respective service. Making an authentication request to an API and interpreting the response code would let the scanner know if it is an active credential.Word Boundaries: Ensure the pattern is surrounded by non-alphanumeric characters (e.g. \bghp_...\b), to avoid matching base64 blobs or gibberish.Keywords: Contextual terms nearby (e.g. “github” or “openai”) can better infer the token’s source or use. This works well for many credential-like secrets, but for some tools this isn’t done in a way that is much more clever than running grep. Take another example: JavaScript const s = "h@rdc0ded-s3cr3t"; const t = jwt.sign(payload, s); There’s no unique prefix in cases like this. No format. But it’s still a secret, and if leaked, it could let an attacker forge authentication tokens. Secret scanners that only look for credential-shaped strings would miss this entirely. A Few Common Secret Blind Spots 1. Hardcoded JWT Secrets In a review of over 2,000 Node.js modules using popular JWT libraries, many hardcoded JWT secrets were found: JavaScript const opts = { secretOrKey: "hardcoded-secret-here" }; passport.use(new JwtStrategy(opts, verify)); These are not always caught by conventional secret scanners, because they don’t follow known token formats. If committed to source control, they can be exploited to sign or verify forged JWTs. The semantic data flow of a hardcoded secret to an authorization function can lead to much better results. 2. JWTs With Sensitive Payloads A subtle but serious risk occurs when JWTs are constructed with entire user objects, including passwords or admin flags: JavaScript const token = jwt.sign(user, obj); This often happens when working with ORM objects like Mongoose or Sequelize. If the model evolves over time to include sensitive fields, they may inadvertently end up inside issued tokens. The result: passwords, emails, or admin flags get leaked in every authentication response. 3. Secrets Hidden by Word Boundaries In a separate research survey project, hundreds of leaks were detected from overfitting word boundaries. Word boundaries (\b) in regex patterns are used to reduce noise by preventing matches inside longer strings. But they also miss secrets embedded in HTML, comments, or a misplaced paste: JavaScript {/* <CardComponent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nents> */} Scanners requiring clean boundaries around the token will miss this even if the secret is valid. Similarly, URL-encoded secrets (like in logs or scripts) are frequently overlooked: JavaScript %22Bearer%20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n%22 Scanning GitHub Repos and Finding Missed Secrets We wanted to learn how to better tune a tool and make adjustments for non-word boundary checks so tested it with the best secret scanning tools on the market for strengths and weaknesses: GitHub, GitGuardian, Kingfisher, Semgrep, and Trufflehog. The main tokens discovered across a wide number of open-source projects were GitHub classic and fine-grained PATs, in addition to AI services such as OpenAI, Anthropic, Gemini, Perplexity, Huggingface, xAI, and Langsmith. Less common but also discovered were email providers and developer platform keys. We found that few providers we tested detected the valid tokens associated with GitHub.GitHub’s default secret scanning did not detect OpenAI tokens within word-boundaries, this includes push protection and once leaked within a repository. The other tokens varied per-provider; some detected or missed Anthropic, Gemini, Perplexity, Huggingface, xAI, Deepseek and others. The keys were missed due to either overly strict non-word boundaries or looking for specific keywords that either were in the wrong place or did not exist in the file. Some of the common problem classes with non-word boundaries include: unintentional placement, terminal output, encodings and escape formats, non-word character end-lines, unnecessary boundaries, or generalized regex. Common Token Prefixes and Pattern Examples Here's a sampling of secret token formats that scanners might detect or miss. The reasons for this include the word boundary problems but also the non-unique prefixes can prevent the ability to validate against an authorization endpoint as a true secret that has been leaked. Service Providerpatternsrisk factorsGitHubghp_ github_pat_ gho_ ghu_ ghr_ ghs_Multiple formats to look for. Often can be missed if embedded in strings or URL-encoded.OpenAIsk-Using a hyphen can break some boundary-based detection methods. Ambiguity due to overlap with DeepSeek, but inclusion of T3BlbkFJ pattern in some formats can be a signal, but not consistently used.DeepSeeksk-Using a hyphen can break some boundary-based detection methods. Easily misclassified as OpenAI without additional hints.Anthropicsk-ant- Using a hyphen can break some boundary-based detection methods. End pattern of AA and ant- helps with unique identifiecation.Stripesk_live_ sk_test_Shares prefix with other service providers creating collisions for auth validation when discovered.APIDecksk_live_ sk_test_Shares prefixes with Stripe which makes validation difficult.Groqgsk_Similar format but has slightly different identifier which can help with uniqueness.Notionsecret_Common prefix for many services increases prevalence of false positives by not being able to validate authentication.ConvertAPIsecret_Common prefix for many services increases prevalence of false positives by not being able to validate authentication.LaunchDarklyapi-Common prefix for many services increase prevalence of false positives by not being able to validate authentication.Robinhoodapi-Common prefix for many services increase prevalence of false positives by not being able to validate authentication.Nvidianvapi-Allows string to end in a hyphen (-) which can break some boundary-based detection methods. This is just a sample of the many platforms that have secrets. To help safeguard them it is important to distinguish between an example placeholder and the real thing, so being able to uniquely identify the source becomes challenging. Improving Secret Detection To improve the accuracy and completeness of secret detection, consider the following strategies: For Development Teams Avoid hardcoded secrets. Use environment variables or secret managers even if only meant to be a placeholder example because it can fire false positives and risk missing true positives when they occur.Use static analysis. Catch patterns like string literals in crypto functions but also data flow patterns that can cross between files (inter-file) to expose secrets in unexpected ways that can be caught.Automate checking your codebase. Use tools that continuously monitor source code check-ins, preferably through pre-commit hooks to identify whenever secrets are accidentally introduced into the code base. Relying on your SCM provider to do this is not often enough. For Service Providers Use unique, identifiable prefixes for secrets. It helps with detection.Document exact token formats because the transparency makes it easier for tools to catch it. Offer validation endpoints so that development teams can be confident in any findings being true positives.Expire or encourage rotating tokens automatically to minimize damage. Conclusion Secrets aren’t always easy to spot. They’re not always wrapped in clear delimiters, and they don’t always look like credentials. Sometimes they hide in authentication logic, passed into token payloads, or hardcoded during development. We explained how secret detection works, where it falls short, and how real-world leaks occur in ways many scanners don’t expect. From hardcoded JWT secrets to misplaced token strings, the cost of undetected secrets is high but preventable.

The rapid evolution of digital ecosystems has placed test automation at the center of quality assurance for modern software. But as systems grow increasingly distributed, data-sensitive, and security-driven, traditional automation approaches struggle to maintain transparency, consistency, and trust. This is why blockchain technology — once associated primarily with cryptocurrencies — is now becoming a fundamental part of enterprise testing processes. By 2026, blockchain-backed test automation frameworks are no longer conceptual — they are mainstream. Leading enterprises, development teams, and innovative test automation companies are leveraging blockchain to improve traceability, ensure integrity, and create tamper-proof testing ecosystems. Blockchain’s inherent strengths — immutability, decentralization, transparency, and cryptographic security — make it an ideal solution to strengthen test automation pipelines. This article explores the most impactful blockchain use cases in test automation that organizations of all sizes will be using widely in 2026. 1. Immutable Test Execution Logs Test logs are essential for debugging, auditing, and compliance. However, traditional logs can be: Accidentally overwrittenDeliberately alteredLost during environment crashesCorrupted due to misconfiguration Blockchain eliminates these risks by storing test execution logs on a distributed ledger. Why It Matters Logs become tamper-proofEvery action is time-stampedNo single entity controls the recordsQA, DevOps, and auditors can trust the results In regulated industries — banking, healthcare, government — immutable logs are invaluable. By 2026, blockchain-based logging will be one of the most common features in advanced test frameworks provided by any enterprise-grade test automation. 2. Transparent and Traceable Test Data Management Test data consistency is a long-standing challenge in QA. Development, QA, and staging environments often use different versions of data, leading to unpredictable results. Blockchain solves this by enabling: Version-controlled test dataCryptographically verified datasetsSecure sharing of test data across distributed teamsTraceability of who accessed or modified the data Test data becomes a shared source of truth across the organization, eliminating discrepancies. Key Benefits Prevents test failures caused by inconsistent dataStrengthens data governanceSupports compliance with GDPR, HIPAA, PCI DSS, and more By 2026, blockchain-driven test data management will become a standard practice for enterprise systems. 3. Smart Contracts for Autonomous Test Validation Smart contracts — self-executing programs stored on a blockchain — are changing how test validations are handled. Smart contracts can: Automatically validate test resultsApprove or reject build deploymentsTrigger new test flows based on outcomesEnforce business rules in mission-critical transactions For example, in a payment gateway test, the smart contract can validate whether: Transaction rules were followedFees were calculated correctlyFraud detection rules triggered appropriately Why This Is Transformative Test automation moves from static validation to dynamic, autonomous verification, reducing manual oversight and increasing trust in complex systems. 4. Secure Multi-Vendor Testing Ecosystems Modern enterprises rarely work with a single vendor. Multiple partners, outsourcing teams, and automation experts often collaborate on the same project. But this introduces challenges: Who ran which tests?Were the results manipulated?Can logs from external teams be trusted? Blockchain solves this by providing a distributed ledger where every result is independently verifiable, regardless of who executed it. Key Outcomes Zero trust-based collaborationProven authenticity of external test reportsSmoother, audit-ready vendor relationships By 2026, any serious test automation company working with global clients will be expected to use blockchain-backed verification to ensure transparency. 5. Regulatory Compliance and Audit Readiness Industries such as finance, healthcare, insurance, legal tech, and aviation require strict adherence to compliance standards. Blockchain allows organizations to maintain: Immutable test recordsComplete audit trailsIdentity-verified execution historiesAutomated compliance checks through smart contracts Instead of reviewing thousands of logs manually, auditors simply verify blockchain entries — saving time and reducing human error. This is crucial for: FDA software validationFinancial transaction securityInsurance rule automationMedical device software testing By 2026, regulatory bodies increasingly accept blockchain-based evidence as highly trustworthy. 6. Blockchain for CI/CD Pipeline Integrity CI/CD pipelines continuously ingest, build, test, and deploy code. A single compromised configuration can lead to: Security breachesUnverified deploymentsTampered build artifacts Blockchain secures CI/CD pipelines by: Recording all pipeline eventsHashing build artifactsEnsuring deployment authenticityDetecting unauthorized changes This protects the pipeline from internal and external threats. 7. Traceability for AI and Machine Learning Test Cycles AI models require complex testing for: Data accuracyBias evaluationPerformance consistencyVersion tracking Blockchain helps by: Tracking datasets used for each test cycleRecording model versionsEnsuring data integrity during trainingProviding verifiable audit trails for explainability As AI continues to dominate software development, blockchain-backed AI testing will become a major trend. 8. Enhancing Security Testing and Vulnerability Analysis Security testing involves sensitive data, attack vectors, and vulnerability logs. Storing these in traditional databases risks exposure. Blockchain improves security testing by: Securing vulnerability reportsHashing penetration test resultsPreventing tampering by malicious actorsEnsuring secure communication between red and blue teams This is especially important for organizations dealing with critical infrastructure. 9. Test Automation for Blockchain Applications Themselves With more industries adopting decentralized applications (dApps), Web3 platforms, and smart contracts, testing blockchain systems has become a new specialization. Blockchain introduces unique testing challenges: Consensus validationNode synchronizationSmart contract logic testingGas fee accuracyFork handling Blockchain-backed test automation tools are now designed to test blockchain ecosystems — a recursive but necessary trend in 2026. 10. Cross-Enterprise Quality Assurance Networks In sectors like logistics, government services, and finance, multiple organizations collaborate on shared platforms. Blockchain enables: Shared QA frameworksDistributed test verificationIndustry-wide test standardsEnd-to-end transparency For example, a product’s journey through a supply chain can be tested and validated at each stage, with results stored securely in a blockchain network. Future Outlook: Blockchain as a Core QA Standard By 2026 and beyond, blockchain won’t be an optional enhancement for test automation — it will be a foundational part of QA architecture. Enterprises will use blockchain to: Verify deployment integrityValidate automated test outcomesShare trusted results across departmentsMaintain compliance effortlesslyReduce fraud and human error in QA The accelerating adoption of blockchain-backed frameworks is why clients increasingly choose test automation companies with blockchain capabilities over traditional solutions. Conclusion Blockchain is redefining the landscape of test automation in 2026. With its unmatched security, transparency, immutability, and traceability, it solves long-standing problems that traditional testing frameworks could not. Whether it’s smart contract validation, reliable test logs, secure supply chain QA, or multi-vendor collaboration, blockchain is adding trust and intelligence to every stage of the testing lifecycle. Organizations that embrace blockchain-driven testing will enjoy stronger system integrity, faster audits, improved compliance, and higher confidence in software quality. As digital ecosystems grow more complex, blockchain-backed test automation is no longer just a trend — it’s the future of quality assurance. FAQs 1. Why is blockchain used in test automation? Blockchain provides immutable logs, secure test data, and verified execution trails, enhancing trust and transparency in QA processes. 2. Which industries benefit most from blockchain-based testing? Finance, healthcare, logistics, supply chain, government, and insurance see the biggest benefits due to strict compliance and security needs. 3. Can blockchain prevent test result manipulation? Yes. Once test results are recorded on a blockchain ledger, they cannot be altered or deleted, ensuring complete integrity. 4. Is blockchain-integrated testing expensive? Costs have dropped significantly, and many modern QA tools now offer blockchain-backed features at scalable, affordable levels. 5. Do test automation companies use blockchain? Absolutely. By 2026, almost every leading test automation company is adopting blockchain to strengthen test reliability, compliance, and audit-readiness.

Introduction: Why Supply Chain and Network Security Matter Now In 2021, the Log4Shell vulnerability exposed a critical weakness in modern software: we don't know what's inside our containers. A single vulnerable library (log4j) in thousands of applications created a global security crisis that lasted months. Organizations scrambled to answer one simple question: "Are we affected?" Most couldn't answer. The same year, the SolarWinds breach demonstrated another critical gap: even with isolated networks, attackers who breach one container can move laterally through flat network architectures, compromising entire systems. These incidents led to: Executive Order 14028 (May 2021): Requiring Software Bills of Materials (SBOMs) for federal softwareNIST SP 800-190: Guidelines for container network segmentationZero Trust Architecture: Assuming breach and limiting lateral movement This article presents two production-ready labs that address both challenges: supply chain transparency through SBOM generation (Lab 07) and defense-in-depth network security (Lab 08). These aren't theoretical concepts — they're hands-on implementations you can deploy today. Building on the Foundation: This is Part 2 of the Docker Security series. If you're new to Docker security fundamentals, start with Part 1: Docker Security Audit to AI Protection, which covers configuration auditing, container hardening, vulnerability scanning, image signing, seccomp profiles, and AI/ML workload security. This article assumes you understand those fundamentals and takes you deeper into supply chain security and advanced network architectures. What you'll learn: Generate and maintain SBOMs for vulnerability trackingImplement multi-tier network segmentationConfigure TLS encryption between containersAvoid 8 common network security mistakesIntegrate security into CI/CD pipelines Time investment: 2-3 hours hands-on practicePrerequisites: Docker 20.10+, basic container knowledgeSource code: github.com/opscart/docker-security-practical-guide Part 1: Supply Chain Security with SBOM (Lab 07) The Problem: Invisible Dependencies Consider a typical Docker image: FROM python:3.11-slim COPY requirements.txt . RUN pip install -r requirements.txt COPY app.py . CMD ["python", "app.py"] Question: What packages are actually in this image? Answer without SBOM: "Um... Python 3.11, and whatever's in requirements.txt, and... the base image dependencies... I think?" Answer with SBOM: A complete, machine-readable inventory listing every package, version, license, and dependency — generated in seconds. What Is an SBOM? A Software Bill of Materials (SBOM) is a formal, machine-readable inventory of all software components, libraries, and dependencies in an application. Think of it as an "ingredients label" for software. Key formats: SPDX (Software Package Data Exchange): Linux Foundation standard, ISO/IEC 5962:2021CycloneDX: OWASP standard, security-focusedSyft JSON: Anchore's native format with rich metadata Why SBOMs matter: Rapid vulnerability response: When Log4Shell hit, organizations with SBOMs identified affected systems in minutes, not weeksCompliance: Required for US federal software, increasingly required by enterprisesLicense management: Avoid GPL violations and other licensing issuesSupply chain visibility: Know what's in your containers before deploymentAudit trail: Track component changes over time Lab 07 Architecture Figure 1: Complete SBOM generation and vulnerability scanning workflow showing container image processing through Syft, SBOM generation in multiple formats, Grype vulnerability scanning, and version comparison capabilities. The workflow consists of five main stages: Hands-On: Complete SBOM Workflow (12 Steps) Quick Start Option: Run all 12 steps automatically with the master demo script: This interactive script guides you through all steps with explanations and pauses between each step. For learning individual concepts, follow the manual steps below: run-demo.sh script installing syft and grype, get image ready for nginx (step: 1, 2) Step 1: Install Tools Shell # Install Syft (SBOM generation) curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh -s -- -b /usr/local/bin # Install Grype (vulnerability scanning) curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh -s -- -b /usr/local/bin # Verify installation syft version grype version Step 2: Generate SBOM Shell From a Docker image syft nginx:alpine -o spdx-json > nginx-sbom.json # From a directory syft dir:./myapp -o cyclonedx-json > myapp-sbom.json # Multiple formats at once syft nginx:alpine -o spdx-json=sbom.spdx.json -o cyclonedx-json=sbom.cdx.json What you get (sample output): JSON { "name": "nginx:alpine", "version": "1.25.3", "packages": [ { "name": "alpine-baselayout", "version": "3.4.3-r2", "type": "apk" }, { "name": "openssl", "version": "3.1.4-r5", "type": "apk", "cpe": "cpe:2.3:a:openssl:openssl:3.1.4:*:*:*:*:*:*:*" } // ... 50+ more packages ] } Step 3: Scan for Vulnerabilities # Scan the SBOM grype sbom:./nginx-sbom.json # Or scan image directly grype nginx:alpine Sample output: NAME INSTALLED VULNERABILITY SEVERITY openssl 3.1.4-r5 CVE-2023-5678 High curl 8.1.2-r0 CVE-2023-9012 Medium busybox 1.36.1-r5 CVE-2023-4567 Low Step 4: Compare SBOM Versions # Generate SBOMs for two versions syft myapp:v1.0 -o json > v1.0-sbom.json syft myapp:v2.0 -o json > v2.0-sbom.json # Compare (using provided script) ./compare-sboms.sh v1.0-sbom.json v2.0-sbom.json Comparison output: Added Packages: + requests 2.31.0 (Python) + urllib3 2.0.7 (Python) Removed Packages: - deprecated-lib 1.2.3 (Python) Version Changes: flask: 2.3.0 → 3.0.0 werkzeug: 2.3.7 → 3.0.1 Generate SBOM in Multiple Formats, SPDX, CycloneDX, JSON, XML (step:3, 4) Step 5: Scan SBOM for Vulnerabilities Shell # Scan the SBOM grype sbom:./nginx-sbom.spdx.json # Or scan image directly grype nginx:alpine Sample output: NAME INSTALLED VULNERABILITY SEVERITY openssl 3.1.4-r5 CVE-2023-5678 High curl 8.1.2-r0 CVE-2023-9012 Medium busybox 1.36.1-r5 CVE-2023-4567 Low libcrypto3 3.1.4-r5 CVE-2023-5678 High Step 6: Filter Vulnerabilities by Severity Shell # Only show CRITICAL and HIGH grype nginx:alpine --fail-on high # Only show CRITICAL grype nginx:alpine --fail-on critical # Show only specific severity grype nginx:alpine -o json | jq '.matches[] | select(.vulnerability.severity == "High")' # Export vulnerabilities to JSON grype nginx:alpine -o json > vulnerabilities.json Generating SBOM report and scanning for Vulnerabilities (step: 5, 6) Step 7: Compare SBOM Versions Shell # Generate SBOMs for two versions syft myapp:v1.0 -o json > v1.0-sbom.json syft myapp:v2.0 -o json > v2.0-sbom.json # Compare using provided script ./compare-sboms.sh v1.0-sbom.json v2.0-sbom.json Step 8: Search for Specific Packages Shell # Check if log4j is present (Log4Shell detection) syft nginx:alpine -o json | jq '.artifacts[] | select(.name | contains("log4j"))' # Find all OpenSSL versions syft nginx:alpine -o json | jq '.artifacts[] | select(.name | contains("openssl"))' # Check Python packages syft python:3.11 -o json | jq '.artifacts[] | select(.type == "python")' # Find packages with known vulnerabilities grype nginx:alpine -o json | jq '.matches[] | .artifact.name' | sort -u Step 9: Generate SBOM Report Shell # Build a sample Node.js application ./build-sample-app.sh # Generate SBOM for the custom application syft myapp:latest -o json > output/myapp-sbom.json # View application dependencies cat output/myapp-sbom.json | jq '.artifacts[] | select(.type=="npm") | {name, version}' # This reveals: # - Node.js packages (express, body-parser, etc.) # - System libraries from base image # - Binary dependencies Step:7 Side-by-side SBOM comparison showing added, removed, and updated packages, Step:8 Search specific package, Step:9 SBOM generation for custom Node.js application showing npm packages and dependencies Step 12: Integrate with CI/CD Pipeline Lab 07 includes complete CI/CD pipelines for both Azure DevOps and GitHub Actions: Azure Pipeline (azure-pipeline.yml): - task: Docker@2 inputs: command: build dockerfile: '**/Dockerfile' tags: $(Build.BuildId) - script: | syft $(imageName):$(Build.BuildId) -o spdx-json > sbom.json displayName: 'Generate SBOM' - script: | grype sbom:./sbom.json --fail-on high displayName: 'Scan for Vulnerabilities' - task: PublishBuildArtifacts@1 inputs: pathToPublish: 'sbom.json' artifactName: 'SBOM' Lab 07 Azure Pipeline - Supply Chain Security Workflow Azure DevOps pipeline validating SBOM generation in three formats (SPDX, CycloneDX, Syft JSON), vulnerability scanning with Grype, and supply chain security workflow. Pipeline duration: 18-20 minutes. Key Takeaways: Lab 07 Generate SBOMs in 30 seconds with SyftSupport 3 formats: SPDX, CycloneDX, Syft JSONScan for vulnerabilities automatically with GrypeTrack changes between versionsIntegrate into CI/CD with provided pipelinesMeet compliance requirements (EO 14028) Production impact: One company using this approach reduced vulnerability response time from 14 days to 2 days — a 7x improvement. Part 2: Network Security Architecture (Lab 08) The Problem: Flat Network Architectures Common mistake: YAML # All containers on one network - INSECURE services: web: image: nginx app: image: myapp database: image: postgres # Problem: Web can directly access database! Why this matters: In 2020, a major healthcare breach occurred because attackers compromised a web server and immediately accessed the database, both of which were on the same network with no barriers. The solution: Multi-tier network segmentation with defense in depth. Lab 08: Five Security Scenarios Quick Start: Run all five scenarios with one command: Shell cd labs/08-network-security ./run-all-scenarios.sh This master script executes all scenarios sequentially with explanations between each step (estimated time: 18-22 minutes total). Or run scenarios individually to understand each security layer in detail: Lab 08 provides five interactive scenarios, each building on the previous: Scenario 1: Network Isolation (3-4 minutes) What it teaches: Containers on different networks cannot communicate unless explicitly connected. What it teaches: Containers on different networks cannot communicate unless explicitly connected. # Create isolated networks docker network create frontend-net docker network create backend-net # Web container on frontend only - can't reach backend docker run -d --name web --network frontend-net nginx # Database on backend only - isolated from web docker run -d --name db --network backend-net postgres # API gateway spans both networks - controlled access docker run -d --name api \ --network frontend-net \ --network backend-net \ myapi# API gateway spans both networks - controlled access docker run -d --name api \ --network frontend-net \ --network backend-net \ myapi Key learning: DNS resolution works automatically on custom networks (not on default bridge). # This works docker exec api curl http://db:5432 # API can reach DB # This fails docker exec web curl http://db:5432 # Web cannot reach DB Scenario 2: Multi-Tier Segmentation (4-5 minutes) Figure 2: Production-grade three-tier network architecture showing complete isolation between public, application, and database networks with TLS encryption and internal network protection. Architecture Overview: Public Network: Exposed to internet, contains web tierApplication Network: Internal only, contains business logicDatabase Network: Most secure, internal network with no gateway Real-world example: This architecture prevented a breach in 2022. Attackers compromised the web tier but couldn't reach the database — the app tier's authentication and logging detected the attack. Implementation: YAML version: '3.8' services: web: image: nginx networks: - public-net ports: - "8080:80" app: image: flask-app networks: - public-net # Talks to web - app-net # Talks to database database: image: postgres networks: - app-net # Only accessible from app tier # NO ports exposed to host! networks: public-net: driver: bridge app-net: driver: bridge Security benefits: Web tier cannot directly access databaseAll database requests go through authenticated APIBreach of web tier doesn't compromise dataAPI tier logs and monitors all access Scenario 3: Internal Networks (3-4 minutes) The ultimate isolation: Internal networks have no external gateway — even with -p flag, ports won't bind. networks: secure-db-net: driver: bridge internal: true # No external gateway! services: database: image: postgres networks: - secure-db-net ports: - "5432:5432" # This binding is IGNORED! Result: Database is completely isolated from external access, even by mistake. Use cases: PCI DSS compliance (cardholder data environment)HIPAA compliance (protected health information)Financial services (transaction databases)Any sensitive data store Testing isolation: # Try to access from host - FAILS curl localhost:5432 # Connection refused # Try to access from authorized container - WORKS docker exec app psql -h database -U postgres # Try to access from authorized container - WORKS docker exec app psql -h database -U postgres Scenario 4: TLS Encryption (4-5 minutes) Key insight: Network isolation ≠ encryption. Containers on the same network can sniff traffic. When TLS is required: Multi-tenant environments (different customers)Compliance requirements (HIPAA, PCI DSS, SOC 2)Sensitive data transmission (passwords, PII, financial)Zero-trust architectures Lab 08 includes complete certificate generation: # Generate self-signed CA and server certificates ./certs/generate-certs.sh # Output: # ✓ ca.pem (Certificate Authority) # ✓ ca-key.pem (CA private key) # ✓ server-cert.pem (Server certificate) # ✓ server-key.pem (Server private key) nginx TLS configuration (nginx-tls.conf): server { listen 443 ssl http2; server_name localhost; # TLS certificates ssl_certificate /etc/nginx/certs/server-cert.pem; ssl_certificate_key /etc/nginx/certs/server-key.pem; # Strong TLS configuration ssl_protocols TLSv1.2 TLSv1.3; ssl_ciphers HIGH:!aNULL:!MD5; ssl_prefer_server_ciphers off; # Security headers add_header Strict-Transport-Security "max-age=63072000" always; add_header X-Frame-Options DENY always; location / { proxy_pass http://app:5000; } } Testing TLS: # Without certificate verification (insecure) curl -k https://localhost:8443/health # Output: healthy # With certificate verification (secure) curl --cacert certs/ca.pem https://localhost:8443/health # Output: healthy (certificate verified!) # Inspect TLS details openssl s_client -connect localhost:8443 -showcerts # Shows: TLSv1.3, strong ciphers Performance impact: HTTP (no TLS): 29ms per request HTTPS (TLS): 68ms per request Overhead: ~1-5ms (acceptable for security) Scenario 5: Common Misconfigurations (3-4 minutes) The most valuable scenario — learn from others' mistakes: Mistake 1: Default Bridge Network # BAD: No DNS resolution docker run -d nginx # GOOD: Custom network with DNS docker network create app-net docker run -d --network app-net nginx Mistake 2: Host Networking # BAD: Bypasses ALL security docker run -d --network host nginx # GOOD: Bridge with port mapping docker run -d -p 80:80 nginx Mistake 3: Exposed Database Ports # BAD: Database accessible from internet docker run -d -p 5432:5432 postgres # GOOD: Internal network only docker run -d --network internal-net postgres Mistake 4: No Resource Limits # BAD: Can consume all host resources docker run -d nginx # GOOD: Set memory and CPU limits docker run -d --memory="256m" --cpus="1.0" nginx Mistake 5: Running as Root # BAD: Root by default docker run -d nginx # GOOD: Non-root user docker run -d --user 1000:1000 nginxnx Mistake 6: Privileged Mode # BAD: Disables ALL security docker run -d --privileged nginx # GOOD: Specific capabilities only docker run -d --cap-add=NET_ADMIN nginx Mistake 7: Flat Network # BAD: All containers on one network # See Scenario 2 for solution # GOOD: Multi-tier segmentation Mistake 8: No Health Checks # BAD: Docker thinks it's healthy even when crashed docker run -d nginx # GOOD: Health check configured docker run -d \ --health-cmd="curl -f http://localhost/ || exit 1" \ --health-interval=10s \ nginx Defense in Depth: Combining All Layers The power of Lab 08 is combining all five scenarios into a complete production architecture. See Figure 2 above for the complete multi-tier architecture that combines: Layer 1: Network Isolation (Scenario 1) Separate networks for each tierDNS-based service discoveryGateway containers for controlled access Layer 2: Multi-Tier Segmentation (Scenario 2) Public network for web tierApplication network for business logicDatabase network completely isolated Layer 3: Internal Networks (Scenario 3) Database on internal network with no external gatewayEven port mapping (-p flag) is ignoredComplete isolation from external access Layer 4: TLS Encryption (Scenario 4) Web tier uses TLS 1.3Encrypted communication between tiersCertificate-based authentication Layer 5: Best Practices (Scenario 5) Resource limits on all containersHealth checks enabledNon-root usersNo privileged mode Security Result: Breach the web tier (TLS + authentication)Compromise the app tier (separate network)Bypass API authentication (logged)Access the database (internal network) Each layer increases difficulty exponentially. Running the Scenarios Option 1: Complete Walkthrough (Recommended for learning) cd labs/08-network-security ./run-all-scenarios.sh The master script runs all five scenarios sequentially with explanations (18-22 minutes total). Option 2: Individual Scenarios (For targeted learning) ./demo-network-isolation.sh # Scenario 1: 3-4 min ./demo-multi-tier.sh # Scenario 2: 4-5 min ./demo-internal-networks.sh # Scenario 3: 3-4 min ./demo-tls-encryption.sh # Scenario 4: 4-5 min ./demo-misconfigurations.sh # Scenario 5: 3-4 min Option 3: Docker Compose (Production-ready setup) docker compose up -d # Start secure multi-tier architecture docker compose ps # Verify all services running docker compose down # Cleanup Key Takeaways: Lab 08 5 interactive scenarios covering isolation to encryptionProduction-ready patterns for multi-tier architecturesTLS implementation with certificate generation8 common mistakes and how to fix themDefense in depth combining all techniques18-22 minutes total hands-on learning CI/CD Integration Lab 08 includes a comprehensive Azure DevOps pipeline that validates all network security scenarios automatically on every commit: Azure DevOps pipeline executing all five network security scenarios in parallel, reducing feedback time from 20+ minutes to under 5 minutes through efficient parallel execution. Pipeline Architecture: Stage 1: Validate Scripts - ShellCheck linting for all demo scriptsStage 2: Test Network Security- All 5 scenarios run in parallel (2m 45s) Scenario 1: Network IsolationScenario 2: Multi-Tier SegmentationScenario 3: Internal NetworksScenario 4: TLS Encryption (with certificate generation)Scenario 5: Common MisconfigurationsStage 3: Test Docker Compose - Validates both secure and insecure compose filesStage 4: Integration Test - Runs master script with all scenariosStage 5: Validate Documentation - README and script verificationStage 6: Final Cleanup - Resource cleanup Key Features: Parallel Execution: All scenarios run simultaneously for rapid feedbackTLS Validation: Automatic certificate generation and verificationMisconfiguration Detection: Identifies common security mistakesTotal Duration: 5 minutes (vs 20+ minutes sequential) The parallel execution dramatically reduces CI/CD feedback time while maintaining comprehensive security validation. This enables rapid iteration during development without compromising security testing coverage. Pipeline configuration: azure-pipelines.yml Part 3: Integration and Production Deployment Combining SBOM and Network Security These labs work together for complete security: Lab 07 (Supply Chain) ensures you know what's IN your containers: Which packages and versionsKnown vulnerabilitiesLicense complianceDependency changes Lab 08 (Network) ensures you control HOW containers communicate: Network isolationEncrypted communicationDefense in depthResource management Together, they provide: Preventive security: SBOM scanning catches vulnerabilities before deploymentDetective security: Network monitoring detects lateral movementCorrective security: Segmentation limits blast radius of breaches Real-World Production Architecture Here's how to combine both labs in production: ┌-────────────────────────────────────────────────────────────┐ │ CI/CD Pipeline (Lab 07) │ │ │ │ Code → Build → SBOM Generate → Vuln Scan → Sign → Deploy │ │ (Syft) (Grype) │ └─────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────┐ │ Production Environment (Lab 08) │ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌────────────┐ │ │ │ Public Net │────►│ App Net │────►│ DB Net │ │ │ │ │ TLS │ │ │ (internal) │ │ │ │ [Web] │ │ [App] │ │ [DB] │ │ │ └──────────────┘ └──────────────┘ └────────────┘ │ │ │ │ SBOM attached to each image for vulnerability tracking │ └─────────────────────────────────────────────────────────────┘ Compliance Mapping Both labs help meet multiple compliance requirements: Executive Order 14028 (Federal Software): Lab 07: SBOM generation requiredLab 07: Vulnerability scanningLab 08: Zero-trust architecture PCI DSS 4.0 (Payment Card Industry): Lab 07: Software inventory (Req 6.3.2)Lab 08: Network segmentation (Req 1.2.1)Lab 08: Encryption in transit (Req 4.1)Lab 08: Internal network (Req 1.2.3) HIPAA (Healthcare): Lab 07: Access controls (§164.308)Lab 08: Network isolation (§164.312)Lab 08: Encryption (§164.312(e))Lab 08: Audit logs (§164.312(b)) SOC 2 Type II: Lab 07: Change management (CC8.1)Lab 08: Logical access (CC6.1)Lab 08: Network security (CC6.6)Both: Security monitoring (CC7.2) Implementation Checklist Before production deployment: Supply Chain Security (Lab 07): Generate SBOMs for all container imagesIntegrate SBOM generation into CI/CDSet up vulnerability scanning (fail on HIGH/CRITICAL)Establish SBOM storage and versioningCreate vulnerability response processSchedule regular SBOM updates (weekly/monthly) Network Security (Lab 08): Design multi-tier network architectureCreate custom networks (not default bridge)Configure internal networks for databasesImplement TLS for inter-container communicationSet resource limits on all containersAdd health checks to all servicesRun as non-root usersAvoid privileged modeDocument network topology Getting Started Prerequisites # Docker and Docker Compose docker --version # 20.10+ docker-compose --version # 2.0+ # Lab 07 tools curl -sSfL https://raw.githubusercontent.com/anchore/syft/main/install.sh | sh curl -sSfL https://raw.githubusercontent.com/anchore/grype/main/install.sh | sh # Lab 08 tools (usually pre-installed) openssl version # For certificate generation Quick Start # Clone repository git clone https://github.com/opscart/docker-security-practical-guide.git cd docker-security-practical-guide # Lab 07: Supply Chain Security cd labs/07-supply-chain-sbom ./demo.sh # 45-60 minutes # Lab 08: Network Security cd ../08-network-security ./demo-isolation.sh # Scenario 1: 3-4 min ./demo-segmentation.sh # Scenario 2: 4-5 min ./demo-internal-network.sh # Scenario 3: 3-4 min ./demo-tls-encryption.sh # Scenario 4: 4-5 min ./demo-misconfigurations.sh # Scenario 5: 3-4 min # Or run all scenarios ./run-all-demos.sh # 18-22 minutes Additional Resources Official Documentation: Syft DocumentationGrype DocumentationDocker NetworkingExecutive Order 14028 SBOM Standards: SPDX SpecificationCycloneDX StandardNTIA SBOM Minimum Elements Security Standards: NIST SP 800-190: Container SecurityCIS Docker BenchmarkOWASP Container Security Community: GitHub RepositoryReport IssuesDiscussions Conclusion Supply chain transparency and network security aren't optional anymore — they're required. Executive Order 14028 mandates SBOMs for federal software, and zero-trust architectures demand network segmentation. The complete labs provide everything you need: working code, architecture diagrams, CI/CD integration, and real-world examples. All open source, ready to deploy. What will you build? Continue Your Docker Security Journey: Part 1: Docker Security Audit to AI Protection - Configuration auditing, container hardening, vulnerability scanning (Labs 01-06)Part 2: This article - Supply chain security and network defense (Labs 07-08)Coming Soon: Lab 09 - Secrets Management and Kubernetes Security Connect: GitHub: @opscartLinkedIn: Shamsher Khan Repository: github.com/opscart/docker-security-practical-guide If you found this valuable: Star the repositoryFork for your own learningShare feedback and improvementsShare with your team Tags: #DockerSecurity #DevSecOps #SBOM #ContainerSecurity #NetworkSecurity #SupplyChain #ZeroTrust #Kubernetes #DevOps #Cybersecurity

Container images are the key components of the software supply chain. If they are vulnerable, the whole chain is at risk. This is why container image security should be at the core of any Secure Software Development Lifecycle (SSDLC) program. The problem is that studies show most vulnerabilities originate in the base image, not the application code. And yet, many teams still build their containers on top of random base images, undermining the security practices they already have in place. The result is hundreds of CVEs in security scans, failed audits, delayed deployments, and reactive firefighting instead of a clear vulnerability-management process. To establish reliable and efficient SSDLC processes, you need a solid foundation. This is where hardened base images enter the picture. This article explores the concept of hardened container images; how they promote SSDLC by helping teams reduce the attack surface, shift security left, and turn CVE management into a repeatable, SLA-backed workflow; and what measurable outcomes you can expect after switching to a hardened base. How the Container Security Issue Spirals Out of Control Across SSDLC Just as the life of an application starts with its programming language, the life of a container begins with its base image. Hence, the problem starts here and can be traced back as early as the requirements analysis stage of the SSDLC. This is because the requirements for selecting a base image — if they exist at all — rarely include security considerations. As a result, it is common for teams to pick a random base image. Such images often contain a full OS with numerous unnecessary components and may harbor up to 600 known vulnerabilities (CVEs) at once. Later, when the containerized application undergoes a security scan at the deployment stage, the results show hundreds of vulnerabilities. Most of them originate from the base image, not the application code, framework, or libraries. And yet, the security team must waste time addressing these flaws instead of focusing on application security. As a result: Vulnerabilities are ignored and make their way to production, orDeployments are delayed because of critical vulnerabilities, orThe team spends hours trying to patch the image. Sometimes, all three happen — if you are especially ‘lucky.’ When the container image finally reaches production, the risks associated with the existing CVEs grow as new critical CVEs appear. The team then scrambles to patch the base image, rebuild, and redeploy, hoping nothing breaks. But the problem doesn’t stop there. During preparation for a security audit, it may turn out that the base image lacks provenance data required by regulations, such as a software bill of materials (SBOM), a digital signature, or a strict update schedule. This makes it difficult for the team to meet audit requirements and may result in more than a fine for noncompliance. The presence of a package manager in the base image can worsen the problem, because the image may contain not only essential packages but many others. It is easy to add additional packages, but not as easy to trace their origin or determine whether they are required — especially when a package contains a critical CVE and you must act quickly. To summarize: a base image is not the only container security concern. However, it is the foundation of the container image — and often contains more security flaws than the application itself. This places unnecessary operational burden on the team and pulls their attention away from what truly requires strengthening and enhancement: the application. Hardened Container Images as an SSDLC Control Point If the foundation is rotten, the building won’t last long. Therefore, you fix the foundation. In the case of container images, you replace the underlying base image. What the team needs is not just another base image but a hardened container image that prevents the issues described above. So, what is a hardened container image? It is a strictly defined, minimal set of components required to run the application, which cannot be changed or inspected externally due to the absence of a package manager. This set of components is: Free from known CVEs from the start, guaranteeing a minimal attack surface throughout the lifecycleInventoried in an SBOM and signed with a digital signature, providing comprehensive security metadataContinuously monitored and patched by the vendor under an SLA, so the SRE and security teams can rely on a defined patch cadence Free from unnecessary packages and known vulnerabilities, a hardened container image reduces the attack surface of production containers immediately. But the image hardening is not just about reducing components — it is about helping teams establish a clear CVE management process where all components are listed, tracked, and continuously patched. As a result, hardened container images integrate naturally into the SSDLC program. Enhancing Secure SDLC Workflow with Hardened Images Thanks to the features described above, hardened container images can be smoothly integrated into SSDLC processes, allowing teams to shift security left without slowing down the release cadence or increasing developers' workload. If teams previously used random base images and dealt with patches and security audits reactively, hardened container images change the game from the start. According to the new workflow: The platform team selects a set of hardened container images as the only allowed bases at the planning stage.These hardened images are enforced during the build stage with CI templates and policies.Security scanners don’t choke on hundreds of CVEs during the testing stage; instead, scan results show only issues that matter.Immutable containers with a drastically reduced attack surface run in production; rolling updates are driven by business needs and base image updates, not manual patching.SBOMs, digital signatures, and SLA-backed patch timelines ensure compliance and simplify security audits.When a critical CVE appears, the vendor updates the hardened image, you rebuild your image on top of it, and the security team closes the ticket — now in days instead of weeks. At the same time, the developers’ workflow barely changes: they simply switch the base image and stop wasting time patching code that isn’t theirs. DIY vs. Vendor-Backed Hardened Images Creating and maintaining your own hardened container images is theoretically possible, but it imposes a tremendous operational burden on your team, effectively requiring them to become Linux and runtime maintainers. This requires: Deep knowledge of OS/runtime intrinsicsContinuous CVE monitoring and triageSigning, versioning, and SBOM policies But building a hardened base image is only part of the task. You must also patch it continuously, which requires: Monitoring security advisories for your distribution and runtime(s)Determining which CVEs matter to your environmentRebuilding images, running tests, coordinating rolloutsCommunicating breaking changes to all teams Therefore, maintaining your own hardened base implies high costs, resulting from engineering time spent maintaining the foundation instead of improving the product. Metaphorically, you must run an ultramarathon while maintaining sprinter speed. Fortunately, there is no need to hire a dedicated team solely for base images. Several reliable vendors — including BellSoft, Chainguard, and Docker — provide ready-made hardened container images for various runtimes. This means you can outsource the hard work of maintaining secure base images to experts who do it full-time. When selecting a vendor that ships hardened container images, make sure they provide: Teams focused on OS security, packaging, and complianceSigned images and standard attestationsSBOMs out of the boxRegularly updated images with tested patchesAn SLA for patchesOS and runtime built from source in every image, guaranteeing that no third-party binary — unknown CVEs or irregular update schedules — is included The full set of features depends on the vendor, so study their offerings carefully and select the base images that best fits your needs. This enables a centralized vulnerability-management process built around a trusted solution and allows engineers to focus on the product. Measurable Outcomes of Migrating to Hardened Container Images Migrating to hardened container images is not just about the abstract notion of "improved security." It’s about transforming the chaos of unmanaged base images and unmanageable CVEs into something measurable and controllable. The table below summarizes key areas where you can track improvements driven by hardened container images: Area/metric Result CVEs per image Low to Zero Scanner integration Major vulnerability scanners support base images; Base OS package ecosystem provides a scanner package Scanner noise Meaningful results, no false-positive alerts Package management Reliable ecosystem of verified packages Mean Time to Patch Days Compliance & Audit SBOMs, standardized images, documented patch flow and SLA Operational burden Low, base image patching is handled by the vendor Conclusion A secure software development lifecycle depends on the integrity of every layer in the stack. Hardened container images form the foundation of this stack and represent one of its key control points. Studies show that the majority of vulnerabilities in containerized workloads originate in the base image. Standardizing on hardened, minimal, vendor-supported base images reduces this risk, improves the signal quality of security scanners, and helps create a clear and auditable patching process. Importantly, migrating to hardened images is not difficult — and, surprisingly, hardened images can even be found for free. Therefore, migrating to hardened container images aligns day-to-day engineering practices with security and compliance objectives, shortens response times to critical vulnerabilities, and reduces the operational overhead of managing CVEs at scale — all without affecting product delivery timelines.

Editor’s Note: The following is an article written for and published in DZone’s 2025 Trend Report, Database Systems: Fusing Transactional Speed and Analytical Insight in Modern Data Ecosystems. Modern databases face a fundamental paradox: They have never been more accessible, yet they have never been more vulnerable. Cloud-native architectures, distributed systems, and remote workforces have modified the dynamics of traditional network perimeters, and the usual security approaches have become obsolete. A database sitting behind a firewall is no longer safe. Breaches can increasingly come from compromised credentials, misconfigured APIs, and insider threats rather than external network attacks. This article provides actionable checklists to help practitioners build databases that are secure, performant, and resilient. We’ve organized these into two main categories: Security and trust Performance and reliability Part 1: Security and Trust Let us first look at the most important security- and trust-related concerns. We will cover zero-trust data architecture, fine-grained authentication, data masking, and secrets/key management, with key steps for each concern. 1. Zero-Trust Data Architecture Traditional security models assume that once inside the network perimeter, traffic could be trusted. This assumption is dangerous in modern cloud environments, where attackers can move laterally once they breach a single service. Zero-trust architecture flips this model by assuming that a breach has already occurred and verifying every access attempt regardless of origin. Here are the key steps to support zero-trust data architecture: Implement network segmentation to isolate database instancesEnforce mutual TLS for all database connectionsDeploy identity-aware proxy layers (e.g., Cloud SQL Auth Proxy, AWS RDS Proxy) Enable audit logging for all database access attemptsUse short-lived credentials with automatic rotationImplement IP allowlisting with just-in-time access for administrative operations For a quick verification test, attempt to connect to your database without proper credentials from an “internal” network segment. It should fail immediately. If it succeeds, the zero-trust implementation has gaps that attackers can exploit. 2. Fine-Grained Authentication and Authorization Broad database permissions create unnecessary risk. Granting SELECT on entire databases when users only need specific tables, or allowing all users to see personally identifiable information (PII) when only certain roles require it, violates the principle of least privilege (PoLP). Row-level security and column-level controls ensure users access only what they absolutely need. Here are the key steps to implement fine-grained authentication and authorization: Implement role-based access control with the PoLPConfigure row-level security policies for multi-tenant applicationsApply column-level permissions to restrict sensitive data (PII, financial info)Use attribute-based access control for dynamic authorization Enable multi-factor authentication for administrative accessIntegrate with enterprise identity providers (e.g., Microsoft Entra ID [Azure AD], Auth0)Regularly audit and review permission assignments As a quick verification step, log in as different user roles and verify that data visibility matches expected permissions. Query system catalogs to identify overly permissive grants that violate least privilege. 3. Data Masking and Tokenization Even authorized users don’t always need to see raw sensitive data. Developers troubleshooting production issues, analysts running reports, and support staff assisting customers can often do their jobs with masked or tokenized data rather than actual credit card numbers, social security numbers, or personal health information. Here are the key steps to support this: Implement dynamic data masking for non-production environmentsUse static data masking for analytics and reporting workloadsDeploy tokenization for payment card data (PCI-DSS compliance) Apply format-preserving encryption where applications require specific data formatsCreate separate masked views for different user tiersDocument which fields are masked and their masking rules As a quick verification step, query sensitive columns as a low-privilege user. Data should appear masked — for example, using **-****-****-1234 vs. a full credit card number — while maintaining referential integrity so that joins and foreign keys still work correctly. 4. Secrets and Key Management Across Clouds Hardcoded credentials remain one of the top causes of data breaches. Examples include developers committing database passwords to Git repositories, configuration files containing API keys in plain text, and connection strings sitting in environment variables without encryption. Proper secrets management is the foundation of database security. Here’s a checklist to implement secrets and key management: Never store credentials in application code or configuration filesUse dedicated secrets managers (e.g., AWS Secrets Manager, GCP Secret Manager)Enable automatic credential rotation (30–90-day cycles)Implement encryption at rest with customer-managed keys Use envelope encryption for sensitive data fieldsStore encryption keys separately from encrypted dataEnable key usage audit trailsTest disaster recovery for key material To verify, search the entire codebase for connection strings or database passwords using tools like git-secrets. Finding any credentials indicates that immediate remediation is needed. Then, attempt to access your database after rotating credentials without restarting applications. Properly implemented secrets management should allow seamless credential updates. Part 2: Performance and Reliability Checklists Let us now look at the most significant concerns around performance and reliability. We will cover monitoring and observability, workload optimization, high availability with fault tolerance, and compliance verification, along with key steps to address each concern. 5. Monitoring and Observability The key motivation for monitoring comes from the fact that you cannot optimize what you do not measure. Comprehensive observability prevents outages by detecting problems before they cascade into full failures. It also enables proactive optimization by revealing bottlenecks, inefficient queries, and resource constraints before they impact users To implement monitoring and observability: Collect the three pillars: metrics, logs, and tracesPerform real user monitoring that collects and analyzes data from actual users as they interact with the applicationMonitor query performance with slow query logsTrack connection pool utilization and saturationSet up alerts for abnormal patterns (e.g., sudden CPU spikes, connection storms) Implement distributed tracing for multi-service transactionsMonitor replication lag in real time Track disk I/O, IOPS, and storage growth trendsUse database-specific tools (e.g., pg_stat_statements, MySQL Performance Schema)Integrate with APM platforms (e.g., Prometheus, Grafana) To verify, intentionally run an expensive query (a full table scan on a large table) and verify that it appears in your monitoring dashboards within 60 seconds. Then, simulate a replica failure by stopping a secondary database instance and confirm that alerting fires within your target detection window. 6. Workload Optimization Most database performance issues come from poorly optimized queries and missing indexes. A single unindexed column in a WHERE clause can transform a sub-millisecond query into a multi-second full table scan. N+1 query patterns, where applications execute hundreds of queries in loops instead of using joins, can bring databases to their knees under load. To optimize workloads: Analyze query execution plans for full table scansCreate indexes on frequently filtered and joined columnsImplement query result caching (Redis, Memcached)Use read replicas to offload analytical queriesConfigure connection pooling Partition large tables by date or key rangeArchive historical data to separate cold storageImplement prepared statements to reduce parsing overheadReview and optimize N+1 query patterns To verify, run EXPLAIN ANALYZE on your top 10 slowest queries (identified from slow query logs) to identify missing indexes or suboptimal execution plans. Look for Seq Scan operations on large tables — these are prime candidates for index creation. 7. High Availability and Fault Tolerance Downtime is expensive both financially and reputationally. Modern databases must survive hardware failures, network partitions, and even entire data center outages without losing data or experiencing extended unavailability. High availability requires redundancy, automated failover, and tested recovery procedures. To support high availability with fault tolerance: Deploy multi-AZ or multi-region replicasImplement automatic failover with health checksTest failover procedures quarterly using techniques like chaos engineering Configure backups with point-in-time recoveryStore backups in separate regions/accountsVerify backup restoration regularly Set up circuit breakers to prevent cascading failuresImplement graceful degradation for read-only modesDocument and practice runbooks for common failure scenariosUse consensus-based replication for strong consistency requirements As a verification step, simulate primary database failure by stopping or network-isolating the primary instance, then measure time to recovery, including detection, failover, and application reconnection. The target should align with the recovery time objective. Additionally, restore from backup to a separate instance and verify data integrity through checksums or row counts. 8. Compliance Verification Tests Beyond implementation checklists, organizations need regular testing to verify that controls remain effective over time. Permissions creep, configuration drift, and forgotten test accounts can undermine even the most well-designed security architectures. Schedule these tests at appropriate intervals based on your compliance requirements and risk tolerance. As part of these tests, take care of the following points: Audit user permissions and remove unused accountsReview audit logs for anomalous access patternsVerify backup completion and test restorationCheck for unencrypted data at restConduct penetration testing on the database layerReview and update security policies Test disaster recovery procedures end to endValidate compliance with GDPR/HIPAA/SOC 2 requirementsCommission a third-party security auditExecute a full-scale disaster recovery testReview and update incident response playbooks Conclusion Building trusted, performant, and scalable databases requires continuous vigilance across security and operational domains. The checklists provided in this article aren’t one-time exercises but represent ongoing practices that should mature alongside the organization’s database infrastructure. By systematically working through these checklists and verification tests, organizations can build database infrastructures that are not only secure and compliant but also performant and resilient enough to support business-critical applications at scale. This is an excerpt from DZone’s 2025 Trend Report, Database Systems: Fusing Transactional Speed and Analytical Insight in Modern Data Ecosystems.Read the Free Report

By Saurabh Dashora CORE

I've spent the better part of two decades watching companies learn hard lessons about security. But nothing prepared me for what I saw unfold in 2024. It started in May. Dell disclosed that attackers had exploited a partner portal API — one they probably thought was "internal" enough not to worry about — to siphon off 49 million customer records. Names, addresses, purchase histories. All of it. The method? Attackers simply created fake accounts and used them to query the API repeatedly. No sophisticated zero-day exploit. No nation-state tradecraft. Just an API that trusted requests because they came from inside the castle walls. That same month, I watched the Dropbox incident unfold. Compromised API keys gave attackers access to production environments, exposing customer data and multi-factor authentication details. The irony wasn't lost on me — a company built on trust, breached through credentials that were implicitly trusted. These weren't isolated incidents. By mid-year, Cox Communications had millions of modems remotely exploitable through an API vulnerability. Trello exposed 15 million user profiles because their API allowed email addresses — private information — to authorize access to account data. The pattern was unmistakable: we've been building APIs as if perimeters still exist. They don't. The numbers tell a story we're not hearing In January, I spoke with a security architect at a Fortune 500 financial services firm. She'd just discovered that her organization had 167% more APIs than the previous year — a finding that tracks with Salt Security's 2024 research. But here's what kept her up at night: her team had no inventory of half of them. "Shadow APIs," she called them. Endpoints spun up during sprints, forgotten after deployments, still accepting traffic two years later with authentication schemes written when JWT was just becoming mainstream. Some didn't even validate tokens properly. The data emerging from industry reports is stark. Twenty-eight percent of organizations experienced actual breaches in 2024 — not near-misses, but confirmed compromises where sensitive data and critical systems fell into adversary hands. Only 21% report high confidence in their ability to detect attacks at the API layer. That means four out of five companies are operating partially blind. Authorization and authentication flaws remain the primary culprits. Wallarm's researchers tracked a 1,025% increase in AI-related CVEs from 2023 to 2024, with 98.9% carrying API implications. Over half the vulnerabilities added to CISA's Known Exploited Vulnerabilities catalog were API-related—up from just 20% in 2023. I keep coming back to that number. It's not a gradual shift; it's a tectonic one. Why perimeter thinking fails at the API layer The traditional security model assumed a clear boundary. Firewalls, VPNs, network segmentation — all designed around the idea that "inside" meant trusted and "outside" meant scrutinized. APIs obliterate that distinction. Every microservice calling another microservice. Every third-party integration. Every mobile app making dozens of background requests. These connections don't respect perimeters. An attacker who compromises a single service can often pivot laterally because internal traffic is trusted by default. I interviewed a developer at a SaaS company that experienced repeated broken object-level authorization (BOLA) exploits throughout 2024. Users were accessing data belonging to other accounts simply by manipulating object IDs in API requests. The vulnerability existed because the API validated that a user was authenticated but never checked if they were authorized to access that specific resource. "We fixed it in production within 48 hours," he told me, "but by then, automated scanners had already indexed thousands of exposed records." Zero Trust architecture operates on a fundamentally different assumption: no request is trustworthy by default. Not from inside the network. Not from a service that authenticated ten seconds ago. Not from a partner you've worked with for years. Every single request must prove its legitimacy — continuously. How Zero Trust actually works (and why it's hard) Implementing Zero Trust for APIs isn't about flipping a switch. It requires rethinking how identity, authorization, and trust are managed across your entire stack. Authenticate everything. This means moving beyond simple API keys to robust mechanisms like OAuth 2.0, mutual TLS, or JSON Web Tokens signed by a trusted authorization server. In conversations with teams adopting Zero Trust, the most successful implementations use short-lived tokens that must be refreshed frequently, limiting the damage if credentials are compromised. Authorize with context. Authentication answers "who are you?" Authorization answers "what can you do?" The distinction matters. Fine-grained access control—enforcing permissions at the object level, not just the endpoint level—prevents the BOLA attacks that compromised PandaBuy's 1.3 million users in April 2024. One architect I spoke with implemented Open Policy Agent (OPA) across their Kubernetes clusters to enforce context-aware policies. Users with expired subscriptions couldn't access premium features, even if they still had valid tokens. Geographic restrictions were enforced programmatically. The policies lived outside the application code, making them auditable and consistent. Encrypt everything, everywhere. TLS isn't just for external traffic anymore. Service-to-service communication inside your cluster needs encryption too. Istio and other service meshes can enforce mutual TLS between microservices, ensuring that even if an attacker gains a foothold, they can't eavesdrop on internal traffic. Log every request, monitor every pattern. Visibility is non-negotiable. API gateways should integrate with SIEM systems, feeding every request into behavioral analytics pipelines. Anomaly detection matters — unusual spikes, deprecated endpoints suddenly seeing traffic, geographic patterns that don't match user profiles. After the breach, one company I studied implemented Falco with eBPF monitoring. Within weeks, they detected unauthorized API calls that traditional network monitoring had missed entirely. Assume breach, limit movement. If an attacker compromises one service, Zero Trust architecture contains the damage. Kubernetes network policies restrict pod-to-pod communication. Role-based access controls (RBAC) ensure services can't reach resources they don't need. The goal is to make lateral movement expensive, slow, and noisy. The CI/CD pipeline as security gatekeeper Security can't be something you bolt on at the end. In late 2024, I watched a team at a healthcare startup integrate static and dynamic application security testing directly into their CI/CD pipeline. Developers couldn't merge code until SAST scans passed. Deployments triggered automated DAST checks against staging environments. The friction was real at first. Builds that once took 15 minutes took 30. But within two months, the number of security issues reaching production dropped by 94%. More importantly, developers started thinking about security earlier, writing code that anticipated threats. Secrets management changed, too. They migrated from environment variables to HashiCorp Vault, rotating API keys automatically. OPA policies ran during build stages, verifying that new endpoints complied with Zero Trust principles before deployment. One engineer described it to me this way: "Security became part of the definition of done. If it wasn't secure, it wasn't finished." What happens when you get it right In late 2024, I profiled a mid-sized SaaS company that had spent the previous year rebuilding their API security from the ground up. They'd been experiencing BOLA exploits monthly. User complaints about data appearing in the wrong accounts were becoming routine. They implemented Istio for encrypted service-to-service traffic. Every internal API call required mutual TLS. They introduced OPA for per-endpoint authorization, tying permissions to user roles and subscription tiers. JWT validation happened at the gateway with rate limiting and request throttling. Prometheus and Falco gave them real-time visibility into API behavior. Six months later, unauthorized access attempts had dropped 96%. Not because attacks stopped — they monitor them constantly — but because the architecture no longer trusted anything by default. The developers, surprisingly, reported minimal friction. Automated policy enforcement meant they didn't have to implement security logic manually in every service. The service mesh handled mTLS transparently. OPA policies were declarative and version-controlled alongside application code. "It's weird," the CTO told me over coffee in October. "Building this way feels more natural now. We used to argue about where to put security checks. Now we just assume everything needs validation and move on." The uncomfortable truth about 2025 API attacks aren't slowing down. They're accelerating. Generative AI is expanding attack surfaces. Sixty-five percent of respondents in Traceable's 2025 State of API Security report view GenAI as a serious to extreme risk. Attackers are using AI to probe APIs faster, finding authorization flaws and injection points with machine efficiency. Traditional web application firewalls weren't built for this. They filter at the edge but don't understand the context of API requests. They can't enforce business logic. A WAF might block obvious SQL injection attempts, but it won't catch a legitimate-looking request that manipulates object IDs to access unauthorized data. The gap between what companies think they've secured and what's actually protected is widening. Only 19% of organizations are highly confident they know which APIs expose personally identifiable information. Fifty-five percent are "somewhat confident." That leaves a quarter essentially guessing. I keep thinking about something a security researcher told me during a conference in August. He'd been analyzing the MOVEit breach — a secure file transfer service compromised when attackers exploited an API endpoint to gain unauthorized access. The vulnerability was well-understood. The fix was straightforward. But outdated security protocols and insufficient validation meant the door stayed open. "These aren't sophisticated attacks," he said. "They're just exploiting the fact that we still build systems assuming trust when we should assume hostility." What comes next If you're building cloud-native applications and your APIs don't implement Zero Trust principles, you're not just behind — you're vulnerable in ways that will become increasingly expensive. The perimeter is gone. The castle-and-moat model failed the moment microservices architectures became standard. Every request, internal or external, authenticated or anonymous, needs verification. Continuous verification. Broken object-level authorization. Broken authentication. Excessive data exposure. These aren't abstract OWASP categories. They're the exact vulnerabilities that compromised Dell, Dropbox, Cox, Trello, PandaBuy, and dozens of other organizations in 2024. Zero Trust isn't a product. It's an architectural philosophy that assumes every request is potentially malicious until proven otherwise. It's OAuth 2.0 and mutual TLS. It's fine-grained authorization enforced at every layer. It's logging everything, monitoring constantly, and responding immediately when patterns deviate. It's also about culture. Security can't live in a separate team that gets consulted at the end. It needs to be embedded in CI/CD pipelines, enforced through automated policy checks, and treated as a first-class requirement from design through deployment. The companies that get this right in 2025 won't just survive the next wave of API attacks — they'll build systems resilient enough to handle threats we haven't even seen yet. The ones that don't? They'll become case studies in the next article I write about why waiting was too expensive.

By Igboanugo David Ugochukwu CORE