Security Resources

DZone's Featured Security Resources

Advanced Middleware Architecture For Secure, Auditable, and Reliable Data Exchange Across Systems

By Abhijit Roy

The increasing need for a system to exchange secure, auditable and reliable data among heterogeneous systems necessitates middleware that incorporates performance, security and traceability. This is provided by the proposed architecture, which utilizes a structured workflow with authentication and security via JWT-based mechanisms performed initially, followed by validation and routing through an API gateway. Validated requests that have been successfully processed are then passed to the service layer, where business logic is executed, transaction auditing is performed, and message processing occurs. Audit data are recorded and authenticated using cryptographic algorithms, such as hash functions (e.g., SHA-256) and HMAC signatures, to guarantee integrity and non-repudiation. Scalability and fault tolerance, together with type safety and consistency, are achieved through asynchronous message processing via a message broker and standardized Pedantic data models, respectively. The proposed architecture offers 6.8 messages per second, higher throughput, and an average latency 2.69 ms lower than 3.5 messages per second. It increases the reliability of transactions and has 100% success rate as opposed to 85% in the legacy systems. User management is upgraded to more than 25 concurrent users as compared to 16 users, and security overhead is also being brought down to 0.2 ms as compared to 3-5 ms. The time required for audit retrieval can also be reduced to less than 2 ms, down from a maximum of 100 ms. The findings validate the ability to roll out high-performance, secure, and fully auditable middleware to mission-critical distributed applications. Introduction The developments of distributed computing have emphasized the need to have a layer of intermediate integration which offers uniform services over and above the capabilities of the operating systems. The middleware tier provides a way to communicate, authenticate, orchestrate, and exchange data across heterogeneous components without application-specific logic. Traditionally, this middleware was only used to provide an interface between front-end clients and back-end systems such as databases, mainframes or special hardware. The modern middleware ecologies have however been developed to facilitate more integration capabilities like service mediation, data transformation, API management, and workflow automation across extremely heterogeneous environments. Modern software systems are becoming more and more information-heavy, and ingest, process and analytics of large amounts of heterogeneous data delivered at high velocity are all required. These demands have increased the use of distributed architecture that can scale to multi-cloud, containerized and geographically distributed environments. Although these distributed systems are flexible and can scale, they also come with major communication, concurrency, consistency, partial failure and coordination challenges. Models of distributed execution and middleware frameworks developed over the past two decades aim to hide this underlying complexity, enabling it to be operated reliably, scalable, and at high performance. The dynamic digitalization of emerging businesses has left a dire requirement of middleware that is capable of providing security and audit amenities with operational dependability. The middleware currently available is usually either performance, security or auditability, but seldom do they offer all three with a single solution. This shortcoming underscores the need for a combined middleware platform that supports mission-critical applications without compromising efficiency. This article is motivated by the necessity to create the gap between security, auditability, and performance in middleware systems. In complex distributed environments, failures in data integrity, traceability, or responsiveness can have significant operational, financial, or regulatory impacts. This study presents an effective solution for real-time, secure, and reliable data exchange between heterogeneous systems by offering a single middleware architecture that addresses these challenges. The main contributions of this article include: Integrated Security and Auditability in Middleware: The proposed architecture integrates authentication, cryptographic integrity checks and auditing of transactions into one architecture that will provide secure and fully traceable data transfer among heterogeneous systems.High-Performance, Scalable Design: The middleware is highly scalable, based on the asynchronous message processing, standardized data models, and decoupled service architecture that enables throughput, latency, and concurrency improvements to be significant, and that there is no tradeoff between strong security and performance.Structured and Standardized Workflow: The framework enforces consistent data validation, type safety, and workflow orchestration through Pedantic models and a layered architectural design, enhancing interoperability and reliability in mission-critical environments.Enhanced Audit and Compliance Efficiency: The middleware increases the effectiveness of auditing and compliance with security and auditing needs through the use of cryptographic verification, extensive logging, and end-to-end traceability that offers verifiable records on controlled areas like health, finance, and industrial systems. Methodology The proposed middleware-based workflow, which guarantees safe, auditable, and reliable information sharing among systems. It starts with a client API consumer with a request that is reflected by the FastAPI middleware, which handles request routing and implements security protocols. The middleware subsequently authenticates the JWT token contained within the request; in case the token is invalid an error response is sent and error logs are written and the workflow is stopped. The request is then forwarded to the audit service where the transaction information is recorded in order to have traceability when the token is valid. The audited request is placed in a message broker queue to facilitate asynchronous processing and enhance system scalability and fault tolerance. The next step in the workflow is the performance testing phase, which tests the responsiveness and stability of the work, and the audit trail testing, a phase handled by cryptographic functions such as hash and HMAC, which verify the integrity of the data and provide non-repudiation. Lastly, the resulting processed information is given out as a structured JSON response having a transaction ID and finalizing the workflow with end-to-end security, verification and accountability. Core Technologies and Development Environment The core technologies used in the proposed Architecture to facilitate the security, auditing, and reliability of data exchange include: Python and FastAPI Framework: FastAPI is a fast Python web framework that was chosen because of its automatic OpenAPI documentation, in-built data validation, Pedantic, and native support of asynchronous operations.JWT Authentication and Security: Stateless authentication is done through JWTs based on HS256 algorithm. The generation and validation of secure tokens are done with the PyJWT (v2.8.0) library.Cryptographic Security Libraries: Python has in-built cryptographic security libraries that offer payload integrity and auditability by using hash functions based on SHA-256 hashing, HMAC-SHA256 digital signatures, use of UUID as transaction identifiers, and standardized use of JSON serialization.Pedantic Data Models: Pedantic models (DataExchangeRequest, AuditLog, User) are fully validated and serializable, which guarantees data integrity, type safety, and automatic API documentation of the entire middleware process.Uvicorn ASGI Server: Uvicorn is the performance ASGI server which can help to deal with numerous asynchronous requests and develop quickly with the help of auto-reload features.Requests Library for API Testing: The Python requests library is a tool used to simulate and test the work of authentication, data exchange, and audit trail verification at the middleware system. Proposed System Architecture The proposed Advanced Secure Middleware Integration Framework follows a structured, secure workflow to facilitate reliable interaction between heterogeneous systems. This starts with System A sending an HTTP request to the middleware, including authentication credentials. The request is authenticated with the help of JWT-based security control and forwarded to an API Gateway to verify the request and find an endpoint. Upon successful validation, the request is handled by components in the service layer that execute business logic, audit, and handle messages. Lastly, the approved and processed data is organized with the help of the standard data models and safely managed and transmitted to System B. This workflow will be secure in terms of access control, data integrity and system interoperability. The architectural levels in this workflow are as follows: External Systems Integration: This layer is a level of interaction between the middleware and the external systems. It allows safe request opening in System A and regulated data delivery to System B, so that loose connection and interoperability is created among heterogeneous platforms.Security Layer: The security layer will apply the authentication and authorization throughout the middleware. It provides JWT-based authentication of credentials and access tokens which allow authorized requests to gain access to internal services.API Gateway Layer: API Gateway layer is the node that acts as the central point of entry to the middleware. It controls request validation, routing and endpoint resolution and offers controlled access to backend services in addition to high-performance and asynchronous request processing.Service Layer: The service layer is where the main business logic of the system. It also deals with message processing, transaction auditing, integrity checks, and service orchestration in a dependable and consistent manner to execute requests.Data Models Layer: The data models layer will provide the standard data designs that are commonly used throughout the middleware. It also provides consistency, correctness and data integrity in the system by implementing type safety and validation with Pedantic models. Evaluation Metrics These measures are used to assess the system's performance, responsiveness, reliability, and the effect of security mechanisms on overall effective operation. Throughput: The throughput is a measure that determines how well a system is able to effectively process messages or requests within a time frame. It indicates the processing capacity of the system in a given workload.Latency: Average latency is the average time that it takes between the request and the response to the request. It consists of processing, queuing, transmission and propagation delays. Success Rate: It is the percentage of success of data exchange transactions end-to-end that are completed successfully assuring security, auditability and reliability.Security overhead: It is the extra latency that security mechanisms, e.g. encryption, authentication, key exchange, or access control, would provide relative to a reference (non-secure) system. These measures provide insight into a system's performance and reliability under different workloads. Results and Discussion This section shows the performance analysis of the middleware integration system using three-layer architecture framework. The tests were performed on a development machine that has an Intel Core i7 processor, 16 GB RAM, and Windows 10. The setup involved in Python 3.9 and FastAPI framework along with JWT authentication and in-memory mock services as well as full audit logging. The table II provides a quantitative analysis of the difference between the traditional middleware systems and the proposed architecture on the basis of the important performance and security metrics. The throughput values become 6.8 messages per second, which implies enhanced processing power. Latency is lowered by an average of 15.2 ms to 2.69 ms and indicates a faster response time. The successful rate increases to 100% as opposed to 85%, proving good end to end transaction processing. Scalability is also improved and the concurrent user support scale is upgraded to over 25 users as compared to 16 users. The security overhead reduces greatly (3-5 ms to 0.2 ms) and the authentication and cryptographic processing are efficient. The audit retrieval time is minimized by 50100ms to 1.89ms, which shows enhanced audit efficiency and traceability. The run times of authentication operations such as credential validation, JWT token generation and token verification are 1.06 s, 1.00 s and 0.50 s respectively, which is low overhead in terms of token-based access control. The performance of audit-related procedures is measured in milliseconds, with audit log creation taking 1.89 ms, integrity verification taking 1.42 ms, and digital signature generation taking 1.20 ms, providing support for audit logging and verification systems. Security compliance check indicates complete compliance with all the needed security controls, with a compliance rate of 100%. The integrity checks, digital signatures, and timestamp accuracy also show 100% completeness of the audit trail in all the categories considered such as transaction logging, integrity checks, and digital signatures. These findings affirm that the middleware is complete security and fully audit-able without being too costly to handle. Conclusion And Future Work The proposed middleware architecture has proven that secure, auditable, and reliable data exchange between heterogeneous distributed systems is possible and can be accomplished at high levels of operational efficiency. The framework has the ability to balance performance, scalability and traceability, by providing JWT based authentication, cryptographic integrity checking, asynchronous message processing, and standardized data models. The experimental testing has shown evident gains when compared to the conventional middleware solutions such as better message processing capacity, lower response time, full acquisition of transaction, better support of multiple concurrent users, and significantly less security and audit processing overhead. The layered architecture style allows interoperability, type safety, and fault tolerance such that the architecture is always known to behave the same way under different loads. Those results prove that high security and good auditability are achievable in middleware platforms and would not impact negatively on system performance, so the architecture is appropriate to use in mission-critical applications of health care, IoT, and industry settings. Future research directions are to integrate the message brokers distributed and the adaptive load-balancing techniques to ensure even more scalability and resiliency. Additional support to blockchain-based immutable audit trails should be used to enhance trust and transparency, and cross-cloud deployment and dynamic resource management should be used to support large-scale and changing system architecture. More

The DevOps Security Paradox: Why Faster Delivery Often Creates More Risk

By Jaswinder Kumar

A few years ago, I was part of a large enterprise transformation program where the leadership team proudly announced that they had successfully implemented DevOps across hundreds of applications. Deployments were faster.Release cycles dropped from months to days.Developers were happy. But within six months, the security team discovered something alarming. Misconfigured cloud storage.Exposed internal APIs.Containers running with root privileges.Unpatched base images being deployed daily. Ironically, the same DevOps practices that accelerated innovation had also accelerated risk. This is the DevOps Security Paradox. The faster organizations move, the easier it becomes for security gaps to slip into production. The Velocity vs Security Conflict Traditional software delivery worked like a relay race. Developers wrote the code. Operations deployed it. Security reviewed it near the end. DevOps changed that model entirely. Instead of a relay race, delivery became a high-speed continuous conveyor belt. Code moves through: Source controlCI pipelinesContainer buildsInfrastructure provisioningProduction deployment Sometimes this entire journey happens in minutes. The problem is that security processes did not evolve at the same speed. Many organizations still rely on: Manual reviewsSecurity gates late in the pipelinePeriodic compliance audits By the time issues are discovered, the code is already running in production. The Hidden Security Gaps in Modern DevOps In my experience working with cloud and DevOps teams, most security issues come from a few recurring patterns. 1. Infrastructure as Code Without Guardrails Infrastructure as Code (IaC) is powerful. Teams can provision entire environments with a few lines of code. But this also means developers can accidentally deploy insecure infrastructure at scale. Common issues include: Public S3 bucketsSecurity groups open to the internetDatabases without encryptionMissing network segmentation Because IaC is automated, one mistake can replicate across hundreds of environments instantly. 2. Container Security Is Often Ignored Containers made application packaging simple, but they also introduced new attack surfaces. Many container images in production today still include: Outdated base imagesHundreds of unnecessary packagesCritical vulnerabilities Developers often pull images from public registries without verification. A single vulnerable dependency can quietly introduce risk into the entire platform. 3. CI/CD Pipelines Become a Security Blind Spot CI/CD pipelines now have enormous power. They can: Access source codeBuild artifactsPush imagesDeploy to productionAccess cloud credentials Yet pipelines are rarely treated as high-value targets. Common risks include: Hardcoded secretsOver-privileged IAM rolesLack of pipeline integrity verificationUntrusted third-party actions A compromised pipeline can become the fastest route to compromise production systems. 4. Identity and Access Sprawl Cloud environments grow quickly. What starts with a few roles and service accounts soon becomes hundreds. Without strong identity governance, teams end up with: Overly permissive IAM rolesLong-lived credentialsUnused service accountsCross-account trust misconfigurations Identity is now the primary attack vector in cloud environments, yet it remains one of the least governed areas. Why Security Teams Struggle to Keep Up The reality is that most security teams were never designed for the pace of DevOps. Traditional security approaches rely heavily on: Ticket-based reviewsStatic compliance checklistsQuarterly audits But modern cloud environments change daily. A Kubernetes cluster may create or destroy hundreds of resources every hour. Manual reviews simply cannot scale. Security must evolve from manual inspection to automated enforcement. The DevSecOps Shift The solution is not slowing down DevOps. The solution is making security move at the same speed as DevOps. This is where DevSecOps becomes critical. Instead of adding security at the end, it becomes embedded throughout the delivery lifecycle. Key practices include: Policy as Code Security rules should be enforced automatically. Tools like Open Policy Agent or Kyverno allow teams to define policies such as: Containers cannot run as rootRequired resource limits must be definedPublic cloud resources must be restrictedEncryption must be enabled These policies run automatically during CI pipelines or Kubernetes deployments. Automated Security Scanning Every pipeline should automatically scan for: Container vulnerabilitiesIaC misconfigurationsDependency risksSecret leaks Developers receive immediate feedback before code reaches production. Secure CI/CD Design CI pipelines themselves must follow security best practices: Short-lived credentialsIsolated runnersSigned artifactsVerified dependencies Pipelines should be treated as critical infrastructure, not just build tools. Continuous Cloud Posture Monitoring Even with preventive controls, misconfigurations still happen. Continuous monitoring tools help detect issues such as: Public resourcesIAM privilege escalation risksCompliance violationsDrift from security baselines Security becomes an ongoing process rather than a periodic audit. Culture Matters More Than Tools One of the biggest lessons I’ve learned after two decades in the industry is this: Security failures rarely happen because tools are missing.They happen because security is treated as someone else's responsibility.When developers view security as a blocker, they find ways to bypass it. But when security is built into the developer workflow, it becomes part of normal engineering. Successful DevSecOps cultures usually follow three principles: Security feedback must be immediateSecurity controls must be automatedSecurity must empower developers, not slow them down The Future of Secure DevOps Over the next few years, we will see security becoming deeply integrated into engineering platforms. Some trends are already emerging: Secure Software Supply ChainsSigned container artifactsZero Trust cloud architecturesPolicy-driven infrastructureAI-assisted security detection Organizations that succeed will not treat security as a checkpoint. They will treat it as an automated system woven into the fabric of their delivery platforms. Final Thoughts DevOps changed how we build and deliver software. But it also changed how attackers find opportunities. Speed without security creates fragile systems. The organizations that thrive will be those that learn to balance velocity with resilience. DevOps helped us move faster. DevSecOps ensures we move fast without breaking trust. Stay Connected If you found this article useful and want more insights on Cloud, DevOps, and Security engineering, feel free to follow and connect. More

Algorithmic Circuit Breakers: Engineering Hard Stop Safety Into Autonomous Agent Workflows

By Williams Ugbomeh

Delta Sharing vs Traditional Data Exchange: Secure Collaboration at Scale

By Seshendranath Balla Venkata

Automating Threat Detection Using Python, Kafka, and Real-Time Log Processing

By Krishnaveni Musku

Cybersecurity with a Digital Twin: Why Real-Time Data Streaming Matters

Cyberattacks on critical infrastructure and manufacturing systems are growing in scale and sophistication. Industrial control systems, connected devices, and cloud services expand the attack surface far beyond traditional IT networks. Ransomware can stop production lines, and manipulated sensor data can destabilize energy grids. Defending against these threats requires more than static reports and delayed log analysis. Organizations need real-time visibility, continuous monitoring, and actionable intelligence. This is where a digital twin and data streaming come together: digital twins provide the model of the system, while a Data Streaming Platform ensures that the model is accurate and up to date. The combination enables proactive detection, faster response, and greater resilience. The Expanding Cybersecurity Challenge Cybersecurity is becoming more complex in every industry. It is not only about protecting IT networks anymore. Industrial control systems, IoT devices, and connected supply chains are all potential entry points for attackers. Ransomware can shut down factories, and a manipulated sensor reading can disrupt energy supply. Traditional approaches rely heavily on batch data. While many logs are collected on a continuous basis or in micro-batches, systems struggle to act on them as quickly. Reports are generated every few hours. Many organizations also still operate with legacy systems that are not connected or digital at all, making visibility even harder. This delay leaves organizations blind to fast-moving threats. By the time the data is examined, the damage is already be done. Supply Chain Attacks Supply chains are now a top target for attackers. Instead of breaking into a well-guarded core system, they exploit smaller vendors with weaker defenses. A single compromised update or tampered data feed can ripple through thousands of businesses. The complexity of today’s global supply networks makes these attacks hard to detect. With batch-based monitoring, signs of compromise often appear too late, giving threats hours or days to spread unnoticed. This delayed visibility turns the supply chain into one of the most dangerous entry points for cyberattacks. Digital Twin as a Cybersecurity Tool A digital twin is a virtual model of a real-world system. It reflects the current state of assets, networks, or operations. In a cybersecurity context, this creates an environment where organizations can: Simulate potential attacks and test defense strategies.Detect unusual patterns compared to normal system behavior.Analyze the impact of changes before rolling them out. But a digital twin is only as good as the data feeding it. If the data is outdated, the twin is not a reliable representation of reality. Cybersecurity demands live information, not yesterday’s snapshot. The Role of a Data Streaming Platform in Cybersecurity with a Digital Twin A Data Streaming Platform (DSP) provides the backbone for digital twins in cybersecurity. It enables organizations to: Ingest diverse data in real time: Collect logs, sensor readings, transactions, and alerts from different environments — cloud, edge, and on-premises.Process data in motion: Apply filtering, transformation, and enrichment directly on the stream. For example, match a login event with a user directory to check if the access is suspicious.Detect anomalies at scale: Use stream processing engines like Apache Flink to identify unusual patterns. For instance, hundreds of failed login attempts from a single IP can trigger an alert within milliseconds.Provide governance and lineage: Ensure that sensitive data is secured, access is controlled, and the entire flow is auditable. This is key for compliance and forensic analysis after an incident. A key advantage is that a Data Streaming Platform is hybrid by design. It can run at the edge to process data close to machines, on premises to integrate with legacy and sensitive systems, and in the cloud to scale analytics and connect with modern AI services. This flexibility ensures that cybersecurity and digital twins can be deployed consistently across distributed environments without sacrificing speed, scalability, or governance. Learn more about Apache Kafka cluster deployment strategies. For a deeper exploration of these data streaming concepts, see my dedicated blog series about data streaming for cybersecurity. It covers how Kafka supports situational awareness, strengthens threat intelligence, enables digital forensics, secures air-gapped and zero trust environments, and modernizes SIEM and SOAR platforms. Together, these patterns show how data in motion forms the backbone of a proactive and resilient cybersecurity strategy. Kafka and Flink as the Open Source Backbone for Cybersecurity at Scale Apache Kafka and Apache Flink form the foundation for streaming cybersecurity architectures. Kafka provides a scalable and fault-tolerant event backbone, capable of ingesting millions of messages per second from logs, sensors, firewalls, and cloud services. Once data is available in Kafka topics, it can be shared across many consumers in real time without duplication. Flink complements Kafka by enabling advanced stream processing. It allows continuous analysis of data in motion, such as correlation of login attempts across systems or stateful detection of abnormal traffic flows over time. Instead of relying on batch jobs that check logs hours later, Flink operators evaluate security patterns as events arrive. This combination of Kafka as the durable, distributed event hub and Flink as the real-time processing engine is central to modern security operations platforms, SIEMs, and SOAR systems. It is the shift from static analysis to live situational awareness. With Kafka and Flink, a digital twin can mirror networks, devices, and processes in real time, detect deviations from expected behavior, and support proactive defense against cyberattacks. The result is a shift from static analysis to live situational awareness and actionable insights. Kafka Event Log as Digital Twin with Ordering, Durability, and Replay A digital twin is only useful if it reflects reality in the right order. Kafka’s event log delivers this with ordering, durability, and replay. Event Log as a Live Digital Twin Kafka’s append-only commit log creates a living record of every event in exact order. This is critical in cybersecurity, where sequence shows cause and effect, not just data points. In network traffic, ordered events reveal brute-force attacks by showing retries in order. Industrial command logs show whether shutdowns were legitimate or malicious. Ordered login attempts expose credential-stuffing. Without this timeline, patterns vanish, and analysts lose context. This is a major advantage of Kafka compared to other cyber data pipelines. Tools like Logstash or Cribl can move data to a SIEM, SOAR, or storage system, but they lack Kafka’s durable, fault-tolerant log. When nodes fail, these tools can lose data. Many cannot replay data at all, or they replay it out of order. Replay and Long-Term Forensics Kafka enables reliable event replay for forensics, simulation, and audits. Natively integrated into long-term storage such as Apache Iceberg or cloud object stores, it supports both real-time defense and deep historical analysis. Its fault-tolerant log preserves ordered event data, allowing teams to reconstruct attacks, validate detections, and train AI models on complete histories. This continuous access to accurate event streams turns the digital twin into a trusted source of truth. The result is stronger compliance, fewer blind spots, and faster recovery. Kafka ensures that security data is not only captured but can always be replayed and verified as it truly happened. Diskless Kafka: Separating Compute and Storage Diskless Kafka removes local broker storage and streams event data directly into object storage such as Amazon S3. Brokers become lightweight control planes that handle only metadata and protocol traffic. This separation of compute and storage reduces infrastructure costs, simplifies scaling, and maintains full Kafka API compatibility. The architecture fits cybersecurity and observability use cases especially well. These workloads often require large-scale near real-time analytics, auditing, and compliance rather than ultra-low latency. Security and operations teams benefit from the ability to retain massive event histories in cheap, durable storage while keeping compute elastic and cost-efficient. Modern data streaming services like WarpStream (BYOC) and Confluent Freight (Serverless) follow this diskless design. They deliver Kafka-compatible platforms that provide the same event log semantics but with cloud-native scalability and lower operational overhead. For observability and security pipelines that must balance cost, durability, and replay capability, diskless Kafka architectures offer a powerful alternative to traditional broker storage. Confluent Sigma: Streaming Security with Domain-Specific Language (DSL) and AI/ML for Anomaly Detection Confluent Sigma is an open-source implementation that brings these concepts closer to practitioners. It combines stream processing with Kafka Streams for data-in-motion processing with an open DSL for the expression of patterns. The power of Sigma is that enables free exchange of known threat patterns rapidly across the community. With Sigma, security analysts can define detection rules using familiar constructs, while Kafka Streams executes them at scale across live event data. For example, a Sigma rule might detect unusual authentication patterns, enrich them with user metadata, and flag them for investigation. SOC Prime is a leading commercial entity behind Sigma. They have built a commercial offering on top of the Confluent Sigma project, adding machine learning that classifies events deviating from normal system behavior. This architecture is designed to be both powerful and accessible. Analysts define rules in Sigma; Kafka Streams (in this example implementation) or Apache Flink (recommended especially for stateful workloads and/or scalable cloud services) ensure continuous evaluation; machine learning identifies subtle anomalies that rules alone may miss. The result is a flexible framework for building cybersecurity applications that are deeply integrated into a Data Streaming Platform. Example: Real-Time Insights for Energy Grids and Smart Meters Energy companies often operate across millions of smart meters and substations. Attackers may try to inject false readings to disrupt billing or even destabilize grid control. With batch data, these attacks might remain hidden for days before anyone notices abnormal consumption patterns. A Data Streaming Platform changes this picture. Every meter reading is ingested in real time and fed into Kafka topics. Flink applications process the stream to identify anomalies, such as sudden spikes in consumption across a region or suspicious commands sent to multiple meters at once. The digital twin of the grid reflects this live state, providing operators with instant visibility. Integration with operational technology (OT) systems is essential. Leading vendors such as OSIsoft PI System (now AVEVA PI), GE Digital Historian, or Honeywell PHD collect time-series data from sensors and control systems. Connectors bring this data into Kafka so it can be correlated with IT signals. On the IT side, tools like Splunk, Cribl, Elastic, or cloud-native services from AWS, Azure, and Google Cloud consume the enriched stream for further analytics, dashboarding, and alerting. This combination of OT and IT data provides a holistic security view that spans both physical assets and digital infrastructure. Example: Connected Intelligence in Smart Factories A modern factory may operate thousands of IoT sensors, controllers, and machines connected via industrial protocols such as OPC-UA, Modbus, or MQTT. These devices continuously generate data on vibration, temperature, throughput, and quality. Each signal is a potential early indicator of an attack or malfunction. A Data Streaming Platform integrates this data flow into a central backbone. Kafka provides the scalable ingestion layer, while Flink enables real-time correlation of machine states. The digital twin of the factory is constantly updated to reflect current conditions. If an unusual command sequence appears, for example, a stop request issued simultaneously to several critical machines, streaming analytics can compare the event against normal operating behavior and flag it as suspicious. Again, data streaming does not operate in isolation. Historian systems like AVEVA PI or GE Digital remain critical for long-term storage and process optimization. These can be connected to Kafka so historical and live data are analyzed together. On the IT side, integration with SIEM platforms such as Splunk or IBM QRadar, or with cloud-native monitoring services, allows security teams to combine plant-floor intelligence with enterprise-level threat detection. By bridging OT and IT in real time, data streaming makes the digital twin more than a model. It becomes an operational tool for both optimization and defense. Business Value of Data Streaming for Cybersecurity The combination of cybersecurity, digital twins, and real-time data streaming is not just about technology. It is a business enabler. Key benefits include: Reduced downtime: Fast detection and response minimize production stops.Lower financial risk: Early prevention avoids costly damages, regulatory penalties, and brand risk that can arise from public breaches or loss of trust.Improved resilience: The organization can continue operating safely under attack.Trust in digital transformation: Executives can adopt new technologies without fear of losing control. This means cybersecurity must be embedded in core operations. Investing in real-time data streaming is not optional. It is the only way to create the situational awareness needed to secure connected enterprises. Building Trust and Resilience with Streaming Cybersecurity Digital twins provide visibility into complex systems. Data streaming makes them reliable, accurate, and actionable. Together, they form a powerful tool for cybersecurity. A Data Streaming Platform such as Confluent integrates data sources, applies continuous processing, and enforces governance. This transforms cybersecurity from reactive defense to proactive resilience. Explore the entire data streaming landscape to find the right open source framework, software product, or cloud service for your use cases. Organizations that embrace real-time data streaming will be prepared for the next wave of threats. They will protect assets, maintain trust, and enable secure growth in an increasingly digital economy.

By Kai Wähner

CORE

Hidden Cyber Threat AI Is Preparing That Some Companies Aren't Thinking About

Cyber threats are in an era where defense and attack are powered by artificial intelligence. While AI has seen a rapid advancement in recent times, it has raised concern among world leaders, policymakers and experts. Evidently, the rapid and unpredictable progression of AI capabilities suggests that their advancement may soon rival the immense power of the human brain. Thus, with the clock constantly ticking, urgent and proactive measures need to be set in place to mitigate unforeseen, looming future risks. According to this research, Geoffrey Hinton (Winner, Nobel Prize in Physics (2024), aka "godfather of AI") has grown more worried since 2023, noting that AI advances faster than expected, excelling at reasoning and deception. Hinton warns that to stay operational, if it perceives threats to its goals, AI could be deceptive. He predicts that AI can spur massive unemployment ( replacing software engineers, routine jobs), soar profits for companies, and create societal disruption under capitalism. He estimates a 10–20% chance of human extinction by superintelligent AI within decades, emphasizing bad actors using it for harm, like bioweapons, and the need for regulation. AI is Not Slowing Down on Attacks Here are a few incidents that prove that artificial intelligence isn't slowing down on attacks: According to a report by Deep Instincts, 75% of cybersecurity professionals had to modify their strategies last year to address AI-generated incidents. According to this post on Harvard Business Reviews, spammers save about 95% in campaign costs using large language models (LLMs) to generate phishing emails. According to a post on Deloitte, Gen AI will multiply losses from deepfakes and other attacks by 32% to $40 billion annually by 2027. According to the Federal Bureau of Investigation, in 2023, crypto-related losses totalled $5.6 billion nationally, accounting for 50% of total reported losses from financial fraud complaints. Imagine how much more was lost from 2024-2025. Hidden Dooms AI is Preparing That Some Companies Are Yet to See Widespread Disruption: The advancement in AI technology is gradually turning AI to a double-edged sword. AI can be used to launch a sophisticated cyberattack that could cause a widespread disruption to critical infrastructure, financial systems and other key sectors within a company and beyond. No wonder, David Dalrymple, an AI safety expert, warns that AI advancement is moving super fast, with the world potentially running out of time for safety preparation. Social Manipulation: It's no longer news that AI has so many fascinating advantages but companies need to have a deep understanding of it, so as not to be doomed by it. Gary Marcus, an AI critic and cognitive scientist, warns that current LLMs are dishonest, unpredictable and potentially dangerous. He further notes that one of the real harms AI is capable of is psychological manipulation, which can be leveraged by attackers to socially manipulate public opinions, spread misinformation that could lead to social unrest and destabilization of company and society. Advent of Superintelligence and Control Problem: With AI, the possibility of creating a Superintelligent agent that surpasses human intelligence (the Creator) is raising eyebrows. Yoshua Bengio said in a Wall Street Journal post, “If we build machines that are way smarter than us and have their own preservation goal, then we are creating a competitor to humanity smarter than us”. Unfortunately, the created Superintelligent AI lacks human ethics and would eventually view humans as obstacles to its goal. That way, humanity won’t be able to control the problem, potentially leading to human extinction or war. Operational Code Bloat or Flawed Value Lock-in: Literally, the AI system's function is dependent on the locked-in value that was programmed. However, with AI’s ability to generate codes, it could add in unwanted features – increasing its vulnerability or attack surface. Thus, an attacker could reprogram the AI system to sabotage via data poisoning or flawed values to pursue evil actions that are detrimental to humanity. Common Faults Caused By Companies #1: Poor Integration of GenAI Tools: The integration of third-party GenAI tools like ChatGPT and similar LLMs, without strict controls, has led to so many data leaks that could enable sabotage or espionage opportunities, as leaked data can be weaponized externally. #2: Full Reliance on AI Agents Without Human Oversight: Full reliance on agentic AI without human guidance has led to some critical accidents. According to research, transport companies such as Tesla and Uber have experienced serious incidents due to an over-reliance on AI without human oversight. #3: Poor Investment In AI Safety and Ethics: Oftentimes, when companies fail to invest in AI safety and ethics, they unknowingly leave themselves wide open to attacks. That's why DeepMinds and OpenAI highlight the importance of investing in their safety and ethics. #4: Lack of Clear Policies and Training: When a company lacks strong and clear policies for AI use and regular end-user training on AI's specific security risks, they open their doors to data leakage and prompt injections. Because even the most secure company could be compromised by an untrained or uninformed employee. #5: Poor Security and Continuous Testing: Literally, AI risk assessment shouldn't be treated as a one-time thing. But many companies fail to conduct risk assessments continuously, leading to system vulnerabilities in which adversarial prompts and data manipulation can occur. How Companies Should Prepare For 2026 Attacks Considering the rate at which the threat landscape is rapidly evolving, companies need to adopt a multilayered defense approach to closely match the kind of tumultuous attacks predicted to occur in 2026. And they are as follows: #1 Prepare for Emerging Threats No system can't be attacked. And yes, AI can attack an AI system. It's safer to prepare ahead by setting these three factors straight: Develop an incident response plan for your company’s defense.Conduct regular security training for employees. And trainers should focus on teaching employees how to treat AI agents as actors with their own identities and how to implement Identity and Access Management (IAM) control to prevent unauthorized access.Educate the company C-Suites on AI-risk as a board-level issue. #2 Develop a Comprehensive AI Policy and Procedure Companies should develop a policy and procedure for the secure and ethical use of AI within their organization. This policy includes defining a role for AI oversight, ensuring data privacy, and implementing access control for AI systems. #3 Automate Security Hygiene and Adopt Continuous Monitoring This is another way to prepare against AI attacks in 2026. By automating a routine task like vulnerability scanning, patch and configuration management reduces the window of attacks. Moreover, intense monitoring of AI agent behaviour and interactions is an ideal way to track unusual activity that could indicate an attack. #4 Have Red Team Test Weaknesses and Share Threat Intelligence Considering the sophisticated nature of AI attacks on companies, it's advisable to have a Red team run a test simulation of AI attacks to identify weak centres. While it's much better for companies to find their weaknesses themselves than for attackers to discover their weak spots, having firsthand information on the latest AI threat from other external sources like ISACs (Information Sharing and Analysis Centre) is another way to prepare for AI attacks.

By Francis Ejiofor

Why Every Defense Against Prompt Injection Gets Broken — And What to Build Instead

I watched a senior engineer spend two weeks hardening their LLM-powered claims assistant against prompt injection. Input sanitization. A blocklist with 400+ attack patterns. A classifier model running in front of the main LLM. Rate limiting. He was thorough. Proud, even. And on day one of the penetration test, the red team got through in eleven minutes using a base64-encoded payload nested inside a PDF attachment. I've seen this scene play out more than once. Teams treat prompt injection like a classic injection vulnerability — filter the inputs, escape the dangerous characters, done. That mental model is wrong. And building on a wrong mental model is how you end up with false confidence that's arguably worse than having no security at all. The Research Nobody Wants to Talk About In late 2025, a joint research team from OpenAI, Anthropic, and Google DeepMind published a paper that should have sent shockwaves through the industry. They tested twelve of the most widely cited published defenses against prompt injection and jailbreaking. Not toy implementations — actual production-grade techniques teams are deploying right now. Every single one was bypassed. Most have success rates above 90%. The paper's title says it plainly: "The Attacker Moves Second." Think about what that means architecturally. Every defense you build is a fixed rule or a trained pattern. An attacker who encounters that defense has infinite time and infinite prompting attempts to probe around it. You ship once. They iterate continuously. This isn't a fair fight, and pretending otherwise is how security theater gets born — the kind that passes code review but fails at 2 a.m. on a Tuesday. "The goal is not to prevent prompt injection. That bar is too high. The goal is to make a successful injection structurally irrelevant." This isn't pessimism — it's a design constraint, the same way we think about SQL injection. We don't rely solely on input validation to prevent SQL injection in mature systems. We use parameterized queries, ORMs, connection pool scoping, and database-level user permissions. The sanitization still exists, but it's not load-bearing. Prompt injection needs that exact same architectural rethinking. Why Defenses Fail: A Taxonomy Before you can design around failure modes, you need to understand why each defense class breaks down in practice. The pattern is consistent. Every defense that focuses on detecting or blocking injection at the perimeter gets defeated by attackers who simply shift their vector. You close the front door; they come through the PDF processor. You add a classifier; they inject through the RAG knowledge base. You harden the system prompt; they poison the context over multiple turns. The root cause isn't poor implementation. It's that current LLM architecture fundamentally blurs the line between instructions and data. Everything is tokens. The model cannot inherently distinguish "this is a command I should follow" from "this is document content I should summarize." Until that distinction exists at the architectural level — not the prompt level — injection remains structurally possible. Designing for When It Succeeds Here's the question that doesn't get asked loudly enough: what happens in your system after a prompt injection succeeds? If the answer is "the model generates a harmful response," that's a problem addressable at the output layer. If the answer is "the model calls a payment API with attacker-controlled parameters," you have a completely different threat profile. That's a privilege and authorization problem. The injection just exploited it. Building the Capability Gate Layer 3 Is Load-Bearing — Build It Like It The single most impactful structural change you can make: the LLM should never be the authorization authority for what it can do. The model decides what it wants to do. A separate, hardened capability gate decides whether it's allowed. This is the core of Google DeepMind's CaMeL framework. The LLM plans. A privileged external executor validates each planned action against a strict allow-list before running it. If the model was injected and now "wants" to exfiltrate data to an external URL, the capability gate says no — because exfiltrating to external URLs was never on the allow-list, regardless of what the model was told mid-session. Python # Capability gate — the LLM proposes tool calls; this gate executes them. # Policy is loaded from config at startup — never derived from LLM output. from dataclasses import dataclass from typing import Any, Callable import jsonschema, hashlib, time, logging @dataclass class ToolCall: name: str params: dict[str, Any] session_id: str class CapabilityGate: def __init__(self, policy: dict): self.policy = policy # set at startup by engineers, not by the LLM self.audit_log = [] def execute(self, call: ToolCall) -> Any: # Step 1 — Is this tool in the allow-list at all? if call.name not in self.policy["allowed_tools"]: self._audit(call, "BLOCKED_UNKNOWN_TOOL") raise PermissionError(f"Tool '{call.name}' not in capability allow-list") tool_policy = self.policy["allowed_tools"][call.name] # Step 2 — Do params match the declared schema exactly? try: jsonschema.validate(call.params, tool_policy["param_schema"]) except jsonschema.ValidationError as e: self._audit(call, "BLOCKED_SCHEMA_VIOLATION", str(e)) raise # Step 3 — Privileged operations require human approval if tool_policy.get("requires_human_approval"): self._audit(call, "PENDING_HUMAN_REVIEW") return self._request_human_approval(call) # Passed all gates — log and execute self._audit(call, "EXECUTED") handler: Callable = tool_policy["handler"] return handler(**call.params) def _audit(self, call: ToolCall, outcome: str, detail: str = ""): entry = { "ts": time.time(), "session": call.session_id, "tool": call.name, "params_hash": hashlib.sha256(str(call.params).encode()).hexdigest()[:16], "outcome": outcome, } self.audit_log.append(entry) logging.info("[GATE] %s | %s | session=%s", call.name, outcome, call.session_id) Key thing to note: line 9 — the policy is loaded from config at startup. An injected model cannot rewrite its own allow-list. No matter what it was told to do, the gate only knows the tools registered by engineers at deploy time. The Quarantined LLM for External Content Indirect injection — malicious instructions arriving inside processed documents, emails, or web pages — is the variant most teams are under-defending. The fix isn't a better filter. It's an architectural separation. Run a second, quarantined LLM instance for all external content. This model has no memory, zero tool access, and no ability to pass instructions into the primary model's context. It extracts facts. It summarizes. It cannot issue commands. The primary model receives only the quarantined model's structured output — never the raw document text. Signed Audit Trails on Every Tool Call Detection isn't prevention. But the difference between catching an incident after 41 days and catching it after 4 hours is entirely a detection problem. Every tool call the LLM proposes — executed or blocked — should be logged with a cryptographic hash of the input prompt and proposed parameters. When an injection succeeds, the audit trail tells you exactly what the model was instructed to do and when. Implementation note: Store tool-call audit logs in an append-only store that the LLM has no write access to. If the model is injected and the attacker tries to cover tracks, the log store needs to be structurally out of reach — not just policy-protected. Use a dedicated service with no LLM-accessible write endpoint, and sign entries with an HMAC key the model cannot observe. The Priority Stack: What to Build First Most teams can't implement all of this at once. If you're triaging, here's the honest priority order based on actual blast-radius impact: Audit and shrink LLM tool access — today. List every API and tool your LLM can invoke. Ask: Does the core use case actually require this? Payment writes, external HTTP calls, and database mutation — all need hard justification. Remove anything unnecessary. Blast radius reduction starts here, before you write a single line of security code.Parameter schema validation at the gate. Before any proposed tool call executes, validate every parameter against a strict JSON schema. An injected model trying to send data to https://attacker.com gets blocked because the URL field only accepts your internal domain pattern — no matter how convincingly the model was instructed otherwise.Quarantine all external document processing. Any content arriving from outside your trust boundary — user uploads, web fetches, email bodies, webhook payloads — passes through a sandboxed extraction layer before the primary model sees it. The primary model gets structured facts. Never raw text from untrusted sources.Signed, append-only audit logging. The forensic cost of not having this, when something goes wrong, dwarfs the engineering cost of building it. Ship this in the same sprint as the gate.Add perimeter detection on top. At this point, input classifiers and pattern blocklists are legitimate noise reduction. They lower the volume of attacks reaching your load-bearing defenses. They just aren't the defenses themselves anymore. Where This Leaves Us The uncomfortable truth that benchmark paper surfaces is something the security community knows well from other domains: you cannot secure a fundamentally porous boundary through inspection alone. You have to redesign around the assumption of compromise. SQL injection was "solved" not because databases got better at detecting malicious strings, but because parameterized queries made the injection structurally irrelevant — the database engine stopped treating user input as code. Prompt injection will follow the same arc. Native token-level trust tagging, separate attention pathways for trusted versus untrusted content, architectural separation of instruction processing from data processing — this is where the real fixes lie. Some of that work is happening in research labs right now, including at the same organizations that published the benchmark study. Until it ships at the model level, the only responsible posture is to assume injection will occasionally succeed, and engineer for containment. Your LLM is not a trusted actor in your system. Build accordingly. The engineer at that insurance company wasn't wrong to build his perimeter defenses. He was wrong to stop there.

By Dinesh Elumalai

CORE

How CNAPP Bridges the Gap Between DevSecOps and Cloud Security Companies

Before CNAPP, DevOps owned code, and cloud security teams were responsible for keeping it safe. But that’s hard to do when you’re not part of the build process. Now, thanks to cloud native application protection platforms (CNAPP), everyone’s on the same page, and doing things in a way that makes sense. This article reviews how CNAPP supports shift-down security by integrating with CI/CD pipelines, and why that not only speeds up the rollout of good, safe apps but ultimately benefits the bottom line. What Urged the Shift in App Development Elite modern application teams are deploying multiple times per day. Traditional tools weren’t meant to keep up. Cloud-native environments introduced new and potentially hazardous security problems such as: Infrastructure defined as codeEphemeral workloads (containers, serverless environments)Microservices architecturesMulti-cloud adoptionRapid CI/CD pipelines As a result, teams relied on a hodgepodge of security tools to get the job done end-to-end: CSPM for misconfigurationsContainer scanningCWPP for securing workloads/applicationsKubernetes securityCIEM for permissions When entire business models rely on the strength of their cloud applications, the siloed tool structure wasn’t cutting it. Different tools were owned by different teams, alert fatigue and security gaps abounded, and developers were left out of the process entirely. For SOC teams, the noise was deafening: chasing disconnected alerts with no way to tell which ones represented a genuine, exploitable risk. The security process didn’t just need to be combined; it needed to be inserted right when builds were underway. NIST SP 800-204 (microservices security framework) states: “The earlier in the SDLC that security is addressed, the less effort and cost is ultimately required to achieve the same level of security.” In comes CNAPP, and now you’ve got the whole thing working together: end-to-end cloud application security that looks for everything that can go wrong, but earlier in the chain. How CNAPP Puts the Security Burden Where It Belongs “Earlier in the chain” used to mean “left.” Now, however, Gartner clarifies that shifting left puts an undue burden on developers. Instead, the idea is to shift it down, not just a direction, but an architectural layer. Security becomes embedded into the infrastructure and platform itself, rather than bolted on as a developer task or a post-deployment inspection. Notes Gartner, “Software engineering leaders should pivot away from ‘shifting left’ approaches. Instead, they should shift down application security and improve collaboration across teams.” That is exactly what a unified CNAPP does. In practice, shifting cloud application security “down” looks like a lot of common-sense changes. Here are just a few. Securing Infrastructure as Code (IaC) CNAPP scans IaC templates (including Terraform and CloudFormation configurations) before you deploy them, so flaws and misconfigurations don’t get copy-pasted into production. Previously, a misconfigured Amazon S3 bucket would be caught only once it was exposed in the wild. CI/CD Container & Image Scanning During image build, CNAPP scans OCI-compliant container images for vulnerabilities, hardcoded secrets, and outdated libraries. It also generates a Software Bill of Materials (SBOM), a full inventory of every component and dependency, so teams have complete supply chain visibility before anything ships. Agentless scanning makes this frictionless for Dev teams: nothing to install, no agents to manage, no pipeline slowdown. Before, a critical CVE would be left to be discovered at runtime. CIEM (Identity & Permissions) Shift-Down CNAPP hunts for excessive permissions – one of the most common cloud risk – as the app is being created. It analyzes cross-account access, service account privileges, and IAM roles for risky entitlements, and suggests least-privilege policies where appropriate, which is core to Zero Trust architecture. Using graph-based analysis, CNAPP can also expose toxic permissions (dangerous combinations that no single-purpose tool can see. For instance, a container with a known vulnerability that also holds an identity with administrative cloud access. That’s the full attack path. On their own, each finding might be a low priority, but together, they’re a critical exploit waiting to happen. Without CNAPP, IAM drift becomes catch-as-catch can (with attackers often finding the flaws first). A Software Quality Problem While we may be tempted to lay the blame with security, the process was always part of the problem. “We have a multi-billion dollar cybersecurity industry because for decades, technology vendors have been allowed to create defective, insecure, flawed software,” Jen Easterly explains. “We don’t have a cybersecurity problem. We have a software quality problem.” CNAPP directly addresses many of the cloud-native risks identified in the OWASP Top 10 for Cloud-Native Applications, including insecure defaults, broken authentication in microservices, and supply chain vulnerabilities. It does this by catching them when they are created instead of after exposure. Why CNAPP Makes Dollars and Sense CNAPP does more than catch flaws faster; it unifies different teams for synergies across the board. Comprehensive CNAPP promotes collaboration between developers, operations, and security teams. Before: Developers wasted time “doing it over” when they could have done it right the first time (with better information from security teams).Cloud security providers wasted cycles finding weaknesses after the fact, then checking again to make sure they’re fixed (when they could have “measured twice, cut once” earlier in the development process)Operations managers dealt with delays and setbacks as security goes back to the drawing board for revisions late in the game. SOC analysts got buried under disconnected alerts, wasting time triaging noise instead of dealing with real threats. And the financial state suffers, too. Companies waste time on “do-overs,” paying their teams to backtrack when that budget could have been spent moving the company forward. New innovations take a backseat to fixing the old. Plus, all the money that’s wasted on PR and clean-up when an app gets breached because cloud security teams couldn’t catch absolutely everything at runtime. SAST and DAST are great final measures at each stage (pre and post deployment) but baking security in at the outset trumps all. How CNAPP Brings Teams Together CNAPP works its magic by following a wider trend towards unifying, exposure-centric platforms; a common theme in the CTEM framework. Where CTEM defines the strategy of managing exposure across a business’s attack surface, CNAPP is the operational layer that executes it in the cloud. It provides the continuous, prioritized visibility that CTEM needs: scanning, correlating, and revealing findings in the context of real exploitability. Without a platform like CNAPP feeding it, CTEM in cloud-native environments remains mostly theoretical. As the intricacies of cloud architecture pull specialties apart, CNAPP brings them back together. Dev teams, security teams, and operations are forced to share what they know, benefiting from tribal knowledge that would otherwise be stuck in siloes. That’s because CNAPP wasn’t just designed to solve a tooling problem, but an organizational one. Everyone saw part of the puzzle, but nobody saw the full attack path. Developers saw DAST resultsOps saw runtime incident alerts, IAM saw permissions driftCloud security saw misconfigurations With CNAPP, all these things are correlated and parsed out where remediation would be most relevant: Developers now get immediate feedback on IaC, vulnerabilities in builds, policy violations in code, and identity risk warnings. That’s because CNAPP integrates earlier on (Git repositories, pull requests, CI/CD pipeline).Operations findings feed improvements as things caught at runtime – misconfigurations, privilege misuse, lateral movement openings – informs development standards and IaC templates. Cloud security leaders guide policy, defining encryption requirements, exposure policies, and least-privilege guardrails that will become automated during the build process. For the SOC, correlated, prioritized findings replace myriad alerts, revealing genuine attack paths. This cuts alert fatigue from a quality-of-life win to force multiplier, focusing teams on real threats. Collaborative effort means that development policies, standards, and procedures get better over time, creating consistently cleaner results. Fewer Vulnerabilities, Faster Apps Not only does CNAPP prevent financial and workday waste; it also helps ambitious teams get ahead. Fewer vulnerabilities mean more consumer trust: in the now, and over time. A more coordinated app development process means teams create synergy, not cover the same ground. This leads to faster output. Work is saved as builds get safer down the line – less for cloud security teams to do and re-do – and organizations gain trust in their ability to churn out safe apps fast. The process becomes dependable and repeatable, not sporadic, clunky, and tinged with luck. The result is accelerated secure cloud-native app delivery, at a time when the appetite for such is only accelerating.

By Anastasios Arampatzis

Part II: The Network That Doesn't Exist: Zero Trust, Service Meshes, and the Slow Death of Perimeter Security

The conversation that reordered my understanding of enterprise network security happened in a conference room in London in early 2019. The CISO of a mid-size financial services firm — precise, methodical, someone whose threat modeling I trusted — was describing her organization's response to a pen test finding. The testers had gotten onto one internal server through a phishing email. From that single initial access point, within seventy-two hours, they had lateral movement access to fourteen other systems, including two that handled customer account data. The perimeter had been intact throughout. The firewall logs showed nothing anomalous crossing the network boundary. Everything that happened after the initial email was internal traffic, authenticated by the fact that it came from inside the network. There was no enforcement, no verification, nothing that asked whether this particular server had any business talking to those other fourteen. She paused before finishing the thought: "Our security model assumed that if you were inside, you were trustworthy. And for twenty years, that was close enough to true to be acceptable. It is no longer close enough." That was six years ago. The industry has spent those six years building the tooling to replace the assumption with verification. We're far enough along that I can say, with some confidence, that zero trust has crossed from aspiration to implementation for organizations with the resources and operational maturity to do it properly. I can say with equal confidence that the gap between those organizations and the median enterprise remains wide. What "Zero Trust" Actually Means When You Strip the Marketing The term has been applied to so many products and approaches that it has acquired a kind of semantic exhaustion. VPN replacements are marketed as zero trust. Identity providers market their services as zero trust. Network segmentation vendors claim zero trust. The risk is that the label gets applied to any improvement over the worst previous practice, diluting the concept until it means only "better than whatever you had before." The core principle is austere and specific: no network location confers trust. A request originating from inside your data center, from a known server, from an authenticated user, is not trusted until it has been verified at the resource it's trying to access — verified for identity, verified for authorization, and encrypted in transit. The implicit trust granted by network position — "this request comes from inside, so it's probably fine" — is explicitly discarded. In a microservices environment, this plays out at every service-to-service call. When the order service calls the inventory service, the inventory service has no reason, under zero trust principles, to simply accept that call because it comes from an internal IP. It should verify the calling service's cryptographic identity. It should check whether that identity is authorized to call this endpoint. It should require that the connection be mutually authenticated — not just the server presenting its certificate to the client, but both parties verifying each other. This is what mutual TLS, implemented through a service mesh, provides. And this is where implementation gets concrete. The Service Mesh as Zero Trust Infrastructure Istio has become the most widely deployed service mesh for Kubernetes environments — not universally loved, but operationally well-understood and supported by a large enough ecosystem that its patterns have become reference implementations. When Istio's PeerAuthentication resource is set to STRICT mode cluster-wide, no pod-to-pod communication is permitted in plaintext. Every connection requires mutual TLS. Envoy proxies, running as sidecars to each service, handle the certificate management automatically — services don't manage their own certificates, the mesh issues them, rotates them, and verifies them at connection establishment. What this accomplishes in practice is something that traditional network segmentation never cleanly solved: workload identity that's cryptographic rather than positional. The inventory service doesn't trust the order service because it comes from a particular IP range or VLAN. It trusts it because it has presented a valid SPIFFE certificate issued by the cluster's certificate authority to the order service's service account. These are short-lived certificates — typically valid for hours, not years — that are automatically rotated by the mesh. Compromise of a certificate has a strictly bounded impact window. The authorization layer builds on top of this identity foundation. Istio's AuthorizationPolicy lets you express rules like: only the order service's identity may call the inventory service's /reserve endpoint, and only using the POST method. Everything else is denied. This is least-privilege access control at the service level, enforced by the infrastructure rather than by application code — which means it applies even if the application has a bug that would otherwise permit unauthorized access. I want to note something that often gets glossed over in the service mesh literature: this approach requires that you trust the mesh's certificate authority. If Istio's Citadel component is compromised, the trust foundation of your entire zero trust architecture is compromised. This is a concentrated risk that needs to be managed — with proper isolation of the mesh control plane, regular audit of issued certificates, and anomaly detection on connection patterns. Zero trust moves the trust boundary; it doesn't eliminate the need for trust anchors. The Lateral Movement Problem and Why mTLS Solves It Specifically The attack scenario that zero trust architectures are specifically designed to defeat is lateral movement — an attacker who has gained access to one service using that foothold to reach others. The Wiz.io research from late 2024 on cloud security incidents consistently surfaced lateral movement as the mechanism by which initial compromises became material breaches. An attacker gains access to a low-privileged service — perhaps through a vulnerability in a third-party library, or a misconfigured credential — and then uses that service's network position to probe and eventually access higher-value systems. In a traditional flat network, the compromised service can reach anything else on the same VLAN. In an mTLS-enforced mesh with strict authorization policies, it can reach only what its cryptographic identity is explicitly permitted to reach. An engineer at a cloud-native startup in Tel Aviv described a red team exercise to me in December 2025 with a detail I found genuinely striking. Their red team, working with internal access to simulate a compromised service, spent two days attempting lateral movement from an initially compromised low-privilege workload. In their previous architecture — before the Istio migration — the same exercise had taken forty minutes to reach a database containing customer PII. With the mesh in place and authorization policies enforced, the red team concluded after forty-eight hours that lateral movement to any high-value system was not achievable without compromising the mesh control plane itself, which was separately hardened. Forty minutes to forty-eight hours, with no ability to reach the target. That's what enforcement at every hop buys you. The Organizational Friction Nobody Warns You About I've watched a handful of zero trust service mesh deployments go from inception to production, and the consistent surprise — even for organizations that thought they'd planned carefully — is the application portfolio audit. Strict mTLS enforcement breaks any communication that isn't prepared for it. Applications that make direct TCP connections without TLS, services that rely on plaintext HTTP for internal health checks, legacy integrations that predate certificate-based authentication — all of these fail when the mesh enforces mutual TLS. Before you can enforce zero trust, you have to inventory every service-to-service communication in your environment and verify that each one can be migrated. In most organizations of any meaningful age, this inventory doesn't fully exist. The enforcement work reveals the inventory work that should have been done years earlier. This is not a reason to avoid the migration; it's a reason to plan a phased rollout that begins in permissive mode — the mesh observes but doesn't enforce — and uses that observability period to build the communication map before enforcement is enabled. The organizations I've seen do this well ran their mesh in permissive mode for sixty to ninety days, used the resulting telemetry to identify every service-to-service call in the environment, and then worked systematically through the exceptions before flipping the enforcement switch. The organizations I've seen struggle skipped the discovery phase and then spent months firefighting broken integrations after enabling strict mode. A platform architect at a European insurance company who managed their Istio rollout in mid-2025 told me that their ninety-day permissive phase identified forty-three internal services communicating in plaintext that no living engineer knew about. Eleven of them were production services handling policyholder data. They had been invisible to the security team precisely because they predated any network monitoring that would have noticed them. Tokens at the Edge, Certificates Inside The zero trust model splits neatly along a boundary that's worth being explicit about: external traffic and internal traffic require different trust mechanisms, handled at different layers. For traffic entering the cluster from outside — users, partners, external services — the standard is JWT validation at the ingress layer. An OAuth2 token issued by a trusted identity provider, validated by the gateway before any request reaches internal services. The gateway enforces that tokens are present, valid, unexpired, and issued by an authorized identity provider. Claims inside the token can flow inward to services that need to know about the requesting user's identity or permissions. For internal service-to-service traffic, JWT tokens are unnecessary overhead because you already have a better identity mechanism: the SPIFFE certificate issued by the mesh to each workload. The authorization policy can reference these SPIFFE identities directly, with no additional token propagation required. The clean separation matters operationally. Your OAuth2 configuration and your mesh configuration have different lifecycles, different failure modes, and different operational teams. Keeping them conceptually and architecturally distinct prevents a common failure mode where a change to external authentication inadvertently affects internal service authorization, or vice versa. A Note on What Zero Trust Isn't There is a consulting-driven tendency to describe zero trust as a destination — a state you achieve and then maintain. I'd argue this framing creates false confidence and deferred risk. Zero trust is a set of ongoing commitments: to verify every request, to enforce least privilege at every boundary, to audit access patterns continuously, and to update policies as systems and threat landscapes change. A service mesh configured for strict mTLS in January 2025 needs review in January 2026, because new services have been added, old policies may no longer reflect current requirements, and the threat model has evolved. The auditing component — reviewing service-to-service communication logs for unexpected access patterns, tracking certificate issuance, verifying that authorization policies match current architectural intent — is the maintenance work that determines whether zero trust remains zero trust or gradually drifts back into implicit permissiveness through accumulated exceptions and overlooked policy changes. None of this is reason to avoid the architecture. The alternative — flat networks, positional trust, the implicit assumption that inside means safe — has been conclusively demonstrated inadequate. But the work of security isn't a project with a completion date. It's an operational commitment. The mesh enforces the policy you've written. Writing the right policy, keeping it current, and auditing whether it's working as intended — that part is still yours. The author covers cloud security, enterprise infrastructure, and supply chain risk. They have reported on technology organizations across North America, Europe, and the Middle East over fifteen years.

By Igboanugo David Ugochukwu

CORE

Part I: The Build You Can’t See Is the One That Will Kill You: Software Supply Chains, SBOMs, and the Long Reckoning After SolarWinds

There is a specific quality of dread that experienced security practitioners get when they think carefully about what happened in December 2020. Not the dread of a novel attack technique, or an adversary with exceptional resources. The dread of recognizing, in granular detail, exactly how many organizations were equally exposed and simply weren't targeted. The SolarWinds compromise — where a trojanized software update was distributed through a vendor's legitimate build pipeline and installed with full trust by thousands of downstream customers — was not primarily a story about sophisticated tradecraft. It was a story about the industry's collective decision to trust software artifacts it couldn't inspect, from processes it couldn't verify, at a scale that made the assumption catastrophically fragile. Four years later, I want to report something encouraging: the reckoning has started. I want to be careful about how encouraging I make it sound, because the progress is real but the baseline was so poor that real progress still leaves us badly positioned. What You're Actually Trusting When You Run a Container Let me ground this concretely, because the abstraction of "software supply chain security" makes the problem feel larger and more theoretical than it is. When an engineer pulls a container image from a registry and runs it in production, they are implicitly trusting: the base image and everything in it, every library and dependency pulled during the build, every tool that touched the build environment, the integrity of the registry itself, and the CI/CD pipeline that produced the image. In most organizations I've visited or spoken with, none of these trust relationships are verified at deployment time. The image runs because it's there and it has the right tag. Full stop. This isn't carelessness — or not only carelessness. It's a rational response to a decade of tooling that made verification difficult and trust implicit. Container registries don't, by default, provide cryptographic guarantees about image provenance. CI pipelines don't, by default, produce signed attestations of what happened during the build. The path of least resistance has always been to pull and run. What CISA recognized, in its updated guidance following the SolarWinds fallout, was that this path of least resistance had become a systemic vulnerability. Their framing — describing SBOMs as "foundational" to supply chain security — was notable precisely because it shifted the language from optional best practice to baseline expectation. For organizations selling software to the US federal government, that shift has teeth. For the broader enterprise market, it's creating regulatory pull that is accelerating adoption in ways that years of security conference talks didn't. The SBOM: An Idea Whose Time Came at Enormous Cost A Software Bill of Materials is, at its most mechanical level, a list. Every component in a software artifact — every library, every package, every dependency, with version numbers, license information, and ideally the provenance of where each came from. The concept isn't new. The automotive industry has maintained bills of materials for physical components for decades, because a recall without knowing which vehicles contain the affected part is an organizational catastrophe. Software engineers resisted the analogy for a long time, and not entirely without reason. Software dependencies are more fluid than physical components, the graph of transitive dependencies can be genuinely enormous, and for most of computing history there was no standard format for expressing this information mechanically. The SBOMs that were produced manually were either incomplete, immediately stale, or both. What changed the equation was tooling maturity. Instruments like Anchore's Syft — which can analyze a container image or filesystem and produce a complete SBOM in either the SPDX or CycloneDX standard format with a single command — made SBOM generation something a CI pipeline could do automatically at build time, for every artifact, without human involvement. The SBOM becomes an artifact of the build, produced and stored alongside the image it describes. The utility becomes apparent the moment a new CVE is published. Before SBOMs, the standard enterprise response to something like Log4Shell — which emerged in December 2021 and affected applications that had pulled the library transitively, often without anyone knowing — was manual triage: engineers individually investigating whether their applications contained the vulnerable package, a process that took days or weeks across large organizations. With a maintained SBOM repository, the same analysis becomes a query. Which of our registered artifacts contain log4j-core in this version range? The answer comes back in seconds. The affected services are known. Remediation can be prioritized and tracked. A vulnerability management lead at a large US healthcare technology company told me in August 2025 that their SBOM infrastructure, built out over the eighteen months following a board mandate in early 2024, had reduced their response time to critical CVEs by roughly 70%. She was careful to note that remediation still takes time — rebuilding and redeploying is not instantaneous — but the triage phase, which had previously been the dominant time sink, was now automated. She knew, within an hour of a CVE publication, exactly which services were affected and in what production environments. Signing Is Not Bureaucracy. It's the Chain of Trust. SBOMs tell you what's in an artifact. Signatures tell you whether you can trust the SBOM itself—and the artifact it describes. Sigstore, the Linux Foundation project that has become the emerging standard for software artifact signing, addresses what was previously the most friction-heavy part of cryptographic signing: key management. Traditional GPG-based signing required managing long-lived private keys, distributing public keys through a web of trust, and maintaining the operational discipline to keep signing keys secure and rotated. In practice, most organizations skipped it because the overhead outweighed the perceived benefit. Sigstore's Cosign tool uses ephemeral keys tied to OIDC identity — the CI pipeline's identity, specifically—and records signatures in a transparency log (Rekor) that makes it auditable and tamper-evident. The workflow becomes: build the artifact, generate the SBOM, sign both using the CI pipeline's identity, push everything to the registry. Anyone verifying the artifact can confirm that this specific image, with this specific content, was produced by this specific pipeline identity, and that the signature hasn't been altered since. What this breaks is a specific and important attack path: the substitution of a malicious artifact after the build. If a registry is compromised, or an artifact is tampered with in transit, the signature verification fails at deployment. The image won't run. This is exactly the attack surface that SolarWinds exploited — a build artifact modified between production and distribution. I want to be precise: Cosign doesn't prevent a malicious build. If the pipeline itself is compromised, the malicious artifact gets a legitimate signature. That's where SLSA — Supply-chain Levels for Software Artifacts — enters. SLSA is a framework for build provenance: cryptographic attestations that link a specific build artifact back to a specific source commit, run in a specific environment, with a specific set of build steps. At higher SLSA levels, these attestations are generated by the build system itself in a way that can't be forged by the build script. It's the difference between an artifact that claims to have been built from this commit, and one that can prove it. The GitHub Actions Reality Check Here is where I want to be honest about where the industry actually is, as opposed to where the framework documentation implies it should be. SLSA Level 3 — the level that provides meaningful provenance guarantees, requiring that the build environment be isolated and the provenance be generated by the build platform rather than the build script — is achievable today on GitHub Actions with their new artifact attestation features, which reached general availability in mid-2024. On other platforms, the path is more complex. Most organizations are not at SLSA Level 3. Many are not at Level 1, which requires only that provenance documentation exists in some form. The gap between policy aspiration and operational reality is substantial, and I've watched enough organizations try to close it to have a realistic sense of what it takes. The organizations making genuine progress share a few characteristics. They've treated SBOM generation and signing as infrastructure requirements rather than security theater — meaning they've built them into platform templates that every team gets automatically, rather than requiring individual teams to implement them. They have an SBOM repository that's actually being used: queried during vulnerability response, checked during compliance reviews, updated on every build rather than on an annual audit cycle. And they have signing verification enforced at deployment time — an admission controller or equivalent that simply won't run an image that lacks a valid signature from an authorized build pipeline. A DevSecOps engineer at a financial services firm in Toronto laid it out plainly during a conversation in October 2025: "The SBOM generation took us a week to implement. Signing took two weeks. Getting enforcement turned on in production took four months, because that's when you find out which of your legacy services don't have build pipelines that can be modified, and which teams have been pulling images from registries that aren't in scope for signing." That four months is the realistic part. The tools are good. The organization is the hard problem. What Compliance Is Getting Right and Getting Wrong Executive Order 14028, signed in May 2021 and still being operationalized through CISA guidance and NIST frameworks, has had a measurable effect on enterprise practice — particularly for organizations in or adjacent to the federal contracting space. The requirement to provide SBOMs for software delivered to government customers has created a forcing function that years of voluntary best practice guidance didn't. The risk, which I've watched materialize in real procurement conversations, is that SBOM compliance becomes a checkbox rather than a capability. An organization produces SBOMs because a contract requires them, stores them in an archive nobody queries, and considers the obligation discharged. The SBOM exists. It is never used. It becomes documentation rather than infrastructure. The difference between an SBOM program and SBOM documentation is whether the SBOMs are integrated into the response workflows that matter: vulnerability triage, incident response, compliance reporting, and deployment policy. If your SBOM is a file attached to a contract deliverable but not connected to the system that decides whether an image can be deployed, you have not improved your security posture. You've improved your audit posture. These are not the same thing.

By Igboanugo David Ugochukwu

CORE

Secure Access Tokens in Web Applications: A Practical Guide From the Field

I’ve spent years reviewing applications after security incidents, conducting code audits, and helping teams rebuild trust after token misuse exposed sensitive data. If there’s one pattern I keep seeing, it’s this: teams underestimate how important it is to secure access tokens in web applications. Access tokens sit at the center of modern authentication. If someone steals or misuses them, they can impersonate users, call APIs, and access protected data without ever knowing a password. Let’s break this down clearly, practically, and based on real industry standards like the OWASP Top 10, NIST Secure Software Development Framework (SSDF), and guidance from CISA and Verizon DBIR. Why Secure Access Tokens Matter More Than You Think Every modern app uses tokens in some form. Whether you’re implementing OAuth 2.0 security, building REST APIs, or managing microservices, token-based authentication is everywhere. Secure access token lifecycle illustrating how tokens are issued, expire, refreshed, and revoked in modern web application authentication flows. Access tokens: Prove identityGrant authorizationControl API accessEnable session continuity If you don’t treat access token security as a first-class concern, your entire authentication model becomes fragile. According to the OWASP Top 10, broken access control continues to rank as one of the most serious web application risks. Many of those cases involve token misuse, improper validation, or poor token storage. Where Vulnerabilities Usually Appear In real audits, token-related weaknesses usually show up in predictable areas. 1. Authentication Systems Improper JWT security best practices often cause: Weak signing keysDisabled signature verificationAccepting unsigned tokensNo audience or issuer validation This opens the door to token forgery and identity spoofing. 2. APIs Poor API authentication security leads to: Missing scope validationNo token expiration checksTrusting tokens without proper introspection This directly affects the protection of the API tokens strategy and backend integrity. 3. Front-End Applications Storing tokens in localStorage creates exposure to an XSS token vulnerability. If an attacker executes JavaScript in your app, they can steal tokens instantly. 4. Databases Leaked refresh tokens stored in plaintext can lead to long-term account takeover. That’s a failure of refresh token security and secure token storage. 5. Third-Party Integrations Misconfigured OAuth integrations weaken the secure implementation of OAuth tokens. Redirect URI misuse is still common. Risk Levels Explained Clearly Security isn’t binary. Token issues range in severity. Minor Vulnerabilities Examples: Missing token expiration enforcementLong but finite token lifetimePoor logging practices These don’t immediately expose data but increase long-term risk. Moderate Security Gaps Examples: Tokens stored in localStorageWeak secret key rotationMissing CSRF protection This level allows token theft under certain conditions, especially with XSS. Critical Exploits Examples: Accepting unsigned JWTsNo token revocationStatic signing keys leaked on GitHub These allow full account takeover or API abuse. Here’s what many teams miss: risk severity changes over time. A “moderate” issue becomes critical once attackers discover it. The Verizon DBIR consistently shows that attackers move quickly once they gain access credentials. Step-by-Step: What to Implement (And What to Avoid) Step 1: Follow JWT Security Best Practices JWT structure breakdown illustrating the three core components — header, payload, and signature — and how they combine to form a secure, signed token. Implement: Strong asymmetric signing (RS256 over HS256 when appropriate)Issuer (iss) validationAudience (aud) validationShort token lifetimesSignature verification every time Avoid: Accepting unsigned tokensUsing default or weak secretsSkipping validation for internal APIs This is how you prevent JWT hijacking in real deployments. Step 2: Use Secure Token Storage Comparison of token storage methods, highlighting the security risks of localStorage and the recommended use of HttpOnly Secure Cookies to reduce XSS token theft. Best practice: Store tokens in HttpOnly cookies JWT formatEnable Secure flagUse SameSite attribute Avoid: localStorage for sensitive tokensExposing tokens in JavaScript-accessible memory This directly reduces XSS token vulnerability risk. Step 3: Strengthen Refresh Token Security Implement: Rotation of refresh tokensImmediate invalidation after useBinding refresh tokens to client fingerprint or session Avoid: Infinite refresh lifetimesStoring refresh tokens without encryption This strengthens the overall bearer token security posture. Step 4: Enforce Token Expiration Strategy A solid token expiration strategy includes: Short-lived access tokens (5–15 minutes typical in many systems)Long-lived refresh tokens with rotationAutomatic re-authentication after inactivity Short lifetimes limit damage if tokens are stolen. Step 5: Enable Token Revocation Real systems must support token revocation: Centralized revocation listOAuth token introspection endpointSession invalidation after password reset Without revocation, stolen tokens remain valid until expiration. Step 6: Protect Against CSRF and XSS Use: Strong CSRF token protectionContent Security PolicyOutput encodingFramework-based sanitization OWASP consistently warns that XSS and CSRF remain active attack vectors. They directly impact and prevent token theft efforts. Common access token attack vectors illustrating how XSS, CSRF, replay attacks, API misconfiguration, and OAuth redirect abuse can compromise token security. When Not to Ignore It There are moments when research and patching aren’t enough. Immediately involve your security team or incident response team if: You detect token reuse from multiple geographic locations.Logs show abnormal API token usage spikes.Signing keys were exposed publicly.Users report unauthorized activity.OAuth redirect URIs were altered. CISA advisories regularly highlight credential misuse as a major incident trigger. Don’t attempt to quietly fix a critical token compromise alone. Common Misconceptions About Access Token Security “HTTPS is enough.” No. HTTPS protects tokens in transit. It does nothing for poor storage or weak validation.“JWT is secure by default.” JWT is a format. Security depends on implementation. Poor configuration breaks JWT security best practices.“Short tokens eliminate risk.”Short expiration helps, but without token revocation, attackers can still act within that window.“OAuth means secure.”OAuth improves architecture, but poor OAuth 2.0 security implementation introduces new risks. Security Lifecycle: What Happens Over Time Security isn’t a one-time setup. Development Phase Threat modelingSecure coding practicesNIST SSDF alignment Pre-Deployment Penetration testingToken misuse simulationAccess control validation Post-Deployment Logging token usageMonitoring anomaliesRegular key rotation If vulnerabilities remain unpatched: Attackers escalate accessAPI abuse increasesTrust erodesRegulatory exposure grows Many breaches escalate slowly. What starts as a poor protection API token design becomes data leakage months later. Security can feel heavy. Especially if you discover token flaws in production. I’ve worked with teams who thought their system was “good enough” until an audit showed otherwise. You’re not alone. Most organizations improve gradually: Fix storage firstImprove validation nextThen implement rotation and revocation Security maturity grows step by step. A Practical Checklist for Secure Access Tokens If you want something concrete, here’s what I personally check: Strong signing algorithmsEnforced expirationRevocation capabilityEncrypted refresh storageHttpOnly cookies for sensitive tokensCSRF token protectionXSS mitigation controlsOAuth redirect validationAPI scope enforcementMonitoring and logging This is how you build reliable access token security. The Future of Token Security Attackers increasingly target identity infrastructure. Verizon DBIR reports repeatedly show that stolen credentials remain a major attack vector. I expect: More token binding mechanismsHardware-backed session protectionStronger OAuth extensionsAutomated anomaly detection for bearer token misuse Teams that ignore token lifecycle management will face: API abuseAccount takeoversCompliance failures Security must evolve with your architecture. Final Thoughts If you want to truly secure access tokens in web applications, focus on lifecycle management, validation rigor, secure storage, monitoring, and response readiness. Tokens represent identity. Identity represents trust. Protect both with discipline, clarity, and steady improvement. Trusted Sources and References This article is based on established cybersecurity standards and industry guidance, including: OWASP Top 10OWASP API Security Top 10NIST Secure Software Development Framework (SSDF)CISA advisoriesVerizon Data Breach Investigations Report (DBIR)Practical field experience in secure authentication architecture No exaggerated breach claims or fabricated statistics were included. The recommendations reflect real-world implementation practices used in enterprise environments. The guidance and recommendations in this article are based on recognized security frameworks, official protocol specifications, and industry-standard research. The following sources informed the technical direction and best practices discussed: OWASP (Open World Wide Application Security Project) OWASP Top 10 – Web Application Security Risks: https://owasp.org/www-project-top-ten/OWASP API Security Top 10: https://owasp.org/www-project-api-security/OWASP JSON Web Token (JWT) Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/JSON_Web_Token_for_Java_Cheat_Sheet.htmlOWASP OAuth 2.0 Security Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/OAuth2_Cheat_Sheet.htmlOWASP Cross-Site Scripting (XSS) Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross_Site_Scripting_Prevention_Cheat_Sheet.htmlOWASP Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html NIST (National Institute of Standards and Technology) NIST Secure Software Development Framework (SP 800-218): https://csrc.nist.gov/projects/ssdfNIST Digital Identity Guidelines (SP 800-63 Suite): https://pages.nist.gov/800-63-3/NIST SP 800-63B – Authentication and Lifecycle Management: https://pages.nist.gov/800-63-3/sp800-63b.html IETF RFC Specifications RFC 7519 – JSON Web Token (JWT): https://datatracker.ietf.org/doc/html/rfc7519RFC 6749 – OAuth 2.0 Authorization Framework: https://datatracker.ietf.org/doc/html/rfc6749RFC 6750 – Bearer Token Usage: https://datatracker.ietf.org/doc/html/rfc6750 CISA (Cybersecurity and Infrastructure Security Agency) CISA Cybersecurity Advisories: https://www.cisa.gov/news-events/cybersecurity-advisories Verizon Data Breach Investigations Report (DBIR) Verizon DBIR – Annual Breach Analysis Report: https://www.verizon.com/business/resources/reports/dbir/

By Syed Saud

Code Security Remediation: What 50,000 Repositories Reveal About PR Scanning

Security teams have gotten good at finding vulnerabilities. Fixing them has always been the hard part. An analysis of remediation patterns across 50,000+ actively developed repositories and 400+ organizations during 2025 reveals a pattern: where a vulnerability is detected has more impact on whether it gets fixed than what the vulnerability is. PR-Detected Findings Get Fixed 9x Faster Static Application Security Testing (SAST) tools scan your source code for security flaws like SQL injection, hardcoded secrets, or missing auth checks. When a scan flags one of these issues (a "finding"), how quickly it gets fixed depends almost entirely on when it was detected. Findings caught during a pull request (PR) are resolved in 4.8 days on average. The same class of finding detected via a full repository scan takes 43 days. That is a 9x difference, and the reason is context. Consider what the PR workflow looks like in practice. A developer opens a PR. A scan runs automatically in CI, and a finding appears as an inline comment: "SQL injection via string concatenation on line 47." The developer is already in that file. The context is fresh. The fix is two lines: SQL # Before — vulnerable query = "SELECT * FROM users WHERE name = '" + username + "'" # After — parameterized query = "SELECT * FROM users WHERE name = ?" db.execute(query, [username]) 63% of PR-detected SAST fixes happen the same day. Now consider the full-scan path. Three months later, a different developer is assigned a Jira ticket for the same class of vulnerability in code written by someone else two years ago. They have to locate the file, rebuild context around unfamiliar code, figure out the right fix, and push it through review. That ticket competes with feature work, and it often sits in the backlog for weeks. The pattern holds for dependency vulnerabilities too, though the gap is smaller. Software Composition Analysis (SCA) findings caught in a PR are resolved in 12.1 days versus 36.4 days for full-scan findings, a 3x improvement. The smaller gap reflects reality: SCA remediation depends on whether a patch exists upstream, which is outside the developer's control. This is not an argument against full scans. PR scanning depends on full scans to establish the baseline that makes diff analysis possible. And some vulnerability classes, particularly cross-file issues where untrusted input enters one file and reaches a dangerous sink in another, require the full codebase context that only a full scan provides. You need both. But the data makes clear that when a finding can be caught at PR time, it is far more likely to get fixed. The 90-Day Cliff Security findings that sit unfixed for 90 days do not get fixed. Teams tell themselves the backlog is temporary, that they will get to those findings next sprint. They rarely do. After 90 days, the original developer may have moved on. The code may have been refactored around the vulnerability. The organizational memory of why this finding matters has faded. What was once a 20-minute fix is now a research project, and research projects lose to feature work every time. Among top-performing organizations (the top 15% by fix rate), only 9.4% of SAST remediations come from findings open longer than 90 days. For the remaining 85%, it is 16%. Leaders are not just fixing more; they are fixing earlier. And the most counterintuitive part: these groups use the same scanning tools. One organization fixes 63% of its critical findings. Another fixes 13%. Same scanner. Same severity filters. Same findings surfaced. The difference is what happens after the scan. In my experience talking to security teams, the gap comes down to three things. Findings sit in a security dashboard that developers never check. Findings reach developers, but without enough context to understand the fix. Or there is no clear owner, so the finding is effectively unassigned. Treat 90 days as an escalation point, not a deadline. At that threshold, every open finding should go through one of three paths: remediate it with dedicated time, formally accept the risk with documented justification, or suppress it as a confirmed false positive. Letting findings sit in the backlog indefinitely without a decision is not risk management. Two Diagnostics to Prioritize Measure your same-day PR fix rate. What percentage of findings detected in PRs get resolved the same day? If it is below 50%, developers are seeing findings but not acting on them. That points to a context problem: the finding does not include enough information to act on, or the developer does not feel ownership over security findings in their code. Leaders hit 63%. Check your 90-day backlog share. What percentage of your total open findings have been sitting for more than 90 days? If a significant portion of your remediations comes from that bucket, your team is spending effort on findings that have already crossed the threshold where fixes are unlikely. PR scanning, CI policies that block merges on high-confidence findings, and faster triage loops all move fixes into the first 30 days, where they are most likely to happen. The dataset behind these benchmarks, including fix rate analysis by OWASP category, specific CWEs, package ecosystem breakdowns, and time-to-fix distributions, comes from the Remediation at Scale report. Dig into the full dataset to see how your numbers compare. Check out the full Semgrep article collection here.

By Braden Riggs

The Platform or the Pile: How GitOps and Developer Platforms Are Settling the Infrastructure Debt Reckoning

There is a specific kind of organizational dysfunction that doesn't show up in sprint velocity metrics or deployment frequency dashboards. It lives in Slack threads where a senior engineer is, for the third time this week, helping a product team figure out why their staging environment behaves differently from production. It lives in the postmortem where someone admits, with genuine embarrassment, that a misconfigured resource limit brought down a service because the relevant YAML file was copied from a two-year-old deployment that nobody remembers creating. It lives in the quiet calculation a platform team lead makes when she realizes her team of six is fielding forty tickets a week, almost none of which required human judgment, and almost all of which could have been prevented by infrastructure that didn't exist yet. This dysfunction has a name now, though it took the industry a while to agree on one. Platform engineering. The practice of building deliberate, opinionated abstractions between developers and the underlying complexity of modern infrastructure. And in 2025, it stopped being a trend and started being a reckoning. The Spreadsheet That Broke a Release Cycle A conversation I keep returning to, from a site reliability engineer at a German industrial software company, October 2024. His team had inherited a Kubernetes environment that had grown organically across three years and two acquisitions. By the time he arrived, they had over four thousand cluster-specific configuration files spread across eleven repositories, maintained by roughly thirty teams who had each developed their own conventions for structuring them. Nobody had planned this. It had accreted, the way technical debt always does — one reasonable decision at a time, in the absence of a shared standard. A team needed a slightly different ingress rule. Another needed non-default resource limits for a memory-intensive service. A third had a custom network policy that predated the company's security baseline. Multiply this across thirty teams over three years and you get a configuration landscape that no single person fully understands. The release that broke him wasn't dramatic. A routine Kubernetes version upgrade that should have taken a long weekend consumed six weeks, because the team couldn't confidently predict which of those four thousand files would conflict with the new API versions and which wouldn't. They needed to test everything. They had no automated way to do it. They did it manually. He told me, with the flat affect of someone who has processed the experience thoroughly: "We weren't doing infrastructure. We were doing archaeology." What GitOps Actually Solves — and What People Get Wrong About It GitOps is one of those terms that has been repeated enough times in conference talks that it has acquired a kind of rhetorical inevitability. Everyone agrees it's the right approach. Fewer people can articulate precisely why, or why it keeps failing to deliver on its promise in practice. The core idea is genuinely simple and genuinely powerful: Git is your system of record for infrastructure state. Tools like Argo CD or Flux run continuously inside your clusters, comparing what's deployed with what's in the repository, and reconciling any differences. A change to infrastructure is a pull request. A rollback is a revert. An audit trail is just the commit history. The benefits are real. I've talked to enough engineering organizations that have made this transition to be confident that they're not imaginary. Drift — the quiet divergence between what you think is deployed and what's actually deployed — is dramatically reduced. Incident response gets faster because rollbacks are mechanical rather than procedural. Security teams can audit changes without asking engineers to reconstruct what happened from memory. But here's what the GitOps advocates tend to understate: Git as a source of truth for infrastructure only works if the things committed to Git are trustworthy representations of intent. If thirty teams are each committing their own raw Kubernetes YAML, with their own conventions, their own interpretations of what a "standard" deployment looks like, you haven't solved the configuration sprawl problem. You've just moved it into version control. You have a very auditable pile. The insight that platform engineering adds to GitOps is the layer that was always implied but rarely explicit: someone has to own what goes into Git. Not the individual teams, working independently with their own preferences and their own copy-paste histories. A platform abstraction, curated by people whose job is to encode organizational best practices into templates that generate correct configuration rather than trust that correct configuration will emerge organically from thirty autonomous teams. The Compiler Metaphor That Actually Lands The frame I've found most useful — borrowed from a conversation with a platform architect in Amsterdam who worked on Humanitec's orchestration model — is the compiler. When a developer writes application code, they don't write machine instructions. They write in a high-level language, and a compiler translates their intent into the machine instructions required to execute it. The developer doesn't need to understand register allocation or instruction pipelining to write correct software. The compiler handles the gap between intent and implementation. An Internal Developer Platform is doing something structurally analogous for infrastructure. A developer describes what they need: a web service, two replicas, monitoring enabled, a Postgres database attached. The platform — the orchestrator, in the language the field has settled on — translates that description into the full complement of Kubernetes manifests, Helm values, network policies, service mesh configuration, and whatever else the organization's standards require. The developer doesn't write those artifacts. They can't misconfigure them. The platform generates them correctly, every time, from templates that the platform team maintains and updates centrally. The compilers metaphor breaks down at the edges, as all metaphors do. But the core intuition — that abstraction layers are how complex systems become manageable — is sound. And the organizational implication is significant: it relocates the complexity from distributed to centralized, from implicit to explicit, from configuration sprawl to versioned platform code. Bechtle's Numbers and Why They're Credible When I first heard the figure — roughly a 95% reduction in configuration file volume after a platform engineering adoption — I was skeptical in the way that I'm always skeptical of round numbers from case studies. Vendor-backed success stories have a tendency to report the metric that flatters the product and omit the ones that complicate the narrative. So I spent some time understanding what that number actually means in the Bechtle context. They implemented a tool called Score, which provides a developer-facing schema for describing workloads at a level of abstraction above raw Kubernetes. A developer says, in essence: my service needs a Postgres database and a Redis cache. The platform resolves that into whatever the underlying environment requires — production might mean managed cloud services, staging might mean containerized versions — without the developer ever seeing the infrastructure-specific YAML. The 95% reduction isn't a fabrication. It's an arithmetic consequence of the architecture. If a hundred services each previously had their own deployment manifests, service definitions, network policies, ingress configurations, and resource quota files — say, ten to fifteen files per service — and the platform now generates all of those from a single five-line developer schema, the math is roughly right. The files still exist. They're generated, not handwritten. No individual team owns them. The platform does. What this buys you operationally is harder to quantify but equally important. When your security baseline changes — new network policy requirements, updated container security contexts, a revised resource limit standard — you update the platform template. Every service gets the update on its next deployment. There's no manual propagation across a hundred repositories. There's no version of the security standard that some teams are on and others aren't. The Ticket Queue as Organizational Symptom One pattern I've noticed repeatedly in platform engineering adoptions, which rarely gets written about because it's organizational rather than technical: the transformation of the platform team's role. Before: platform teams are primarily a service desk. Developers need something new, they file a ticket, a platform engineer interprets the request, configures the infrastructure manually or semi-manually, closes the ticket. The platform team's productivity is measured by ticket throughput. Their ceiling is the number of hours in the day. After: platform teams are primarily a product team. Their customers are developers. Their product is the abstraction layer — the templates, the CLI, the portal, the orchestrator. Their productivity is measured by the quality of the self-service experience they've built. Their ceiling is the value of the platform they've shipped, not the capacity to process requests. This sounds like a subtle distinction. It isn't. I talked with a platform team lead at a UK-based financial services firm in early 2025 who described the before-and-after with unusual precision. Before their IDP rollout, her team averaged about forty tickets per week. After — three months into the rollout, with roughly sixty percent of their internal services onboarded — they were averaging seven. The other thirty-three had become self-service actions that developers completed without human involvement. Her team didn't shrink. They redirected. The people who had been triaging tickets were now building better templates, improving documentation, running office hours that were actually about capability building rather than issue escalation. The work was harder, in the sense of requiring more design thinking. It was also, by her account, significantly more sustainable. The Security Case That Gets Underemphasized GitOps and platform engineering are usually sold on developer productivity. Faster deployments, less toil, better developer experience. These benefits are real and worth pursuing. But I'd argue the security case is at least as strong, and it gets underemphasized in most of the literature. Consider the attack surface of a configuration landscape where every team manages its own infrastructure files, with their own conventions, and deploys through processes they've assembled themselves. Security policies are applied inconsistently, if at all. New vulnerabilities in base images or Helm charts propagate to services that are only updated when someone remembers to update them. Drift between environments means security controls that are present in staging may not be present in production. Now consider the same organization with a centralized platform. Security controls — image scanning, runtime policy enforcement, secret management patterns, network segmentation — are encoded into templates. They're not optional. They're not something individual teams remember or forget. They're the output of the platform, automatically, for every service. When a new CIS benchmark requirement comes through, the platform team ships an updated template. Compliance propagates. I spoke with a CISO at a mid-market enterprise software company in November 2025 who made a point I hadn't heard framed this way before: the audit-readiness argument. His company operates in a regulated sector. Before their platform engineering investment, SOC 2 audit preparation was a two-month project every year, involving manual evidence collection across dozens of teams. After — with every infrastructure change committed to Git, every deployment traceable to a specific approved template version — the audit became primarily an automated evidence export. His estimate: the platform investment paid for itself in audit cost reduction within eighteen months, before accounting for any of the deployment velocity benefits. What This Doesn't Solve I'd be doing readers a disservice if I left the impression that GitOps plus an IDP is a complete answer to infrastructure complexity. It isn't. The templates themselves need maintenance. A platform team that doesn't invest continuously in the quality of its abstractions ends up with a different kind of sprawl — one that lives inside the platform rather than outside it. Opinionated abstractions that made sense in 2023 may actively constrain what teams need to do in 2026. The platform has to evolve with the organization, which means someone has to own that evolution and treat it with the same seriousness as any other product roadmap. The organizational adoption is harder than the technical implementation, in my experience. Developers who have spent years with full control over their own YAML sometimes resist abstractions that feel limiting. Platform teams that haven't operated as product teams before sometimes underinvest in the developer experience of their own tools. Both failure modes are common and both are addressable, but neither is automatic. And there's a dependency risk that doesn't get discussed enough: a well-adopted IDP becomes critical infrastructure. If the orchestrator goes down at the wrong moment, your deployment pipeline stops. The platform team's on-call rotation becomes a central dependency for every team that uses the platform. This is a solvable architecture problem — idempotent reconciliation, robust failure modes — but it has to be designed for explicitly, not assumed. The Organizational Bet Worth Making I've been covering enterprise infrastructure long enough to remember when containerization was a controversial technology decision, when Kubernetes was something you adopted cautiously, when "infrastructure as code" was a novel phrase rather than a baseline expectation. Platform engineering is in that same phase now. The organizations that are doing it well are visibly ahead of those that aren't — not in benchmark numbers, but in the qualitative texture of how their engineering organizations operate. Less firefighting. Less configuration archaeology. Fewer incidents traced back to a YAML file that nobody recognized as the source of truth for anything. The investment required is real. A platform team is a product team, and building a product is expensive and slow before it's cheap and fast. The organizations that have made the investment, in my observation, made it because they did the math on what the alternative was costing them: in engineering time, in incident rate, in developer frustration, in compliance overhead. The pile is always cheaper until it isn't. And by the time it isn't, you're doing archaeology at the worst possible moment. The author covers enterprise infrastructure, developer tooling, and organizational technology strategy. They have reported from engineering organizations across three continents over a fifteen-year career.

By Igboanugo David Ugochukwu

CORE

C/C++ Is Where Vulnerability Programs Go to Guess

Walk into most AppSec reviews, and you'll find a familiar pattern. Python dependencies: fully inventoried. npm packages: tracked and patched. C and C++ code powering the operating system, the embedded firmware, or the performance-critical core of the product? A blank space where the risk assessment should be. This is not a tooling gap that's easy to paper over. C and C++ do have package managers, but adoption is still ramping, and they are dependent on the operating system and build environment. Libraries get vendored directly into repositories. Static linking buries third-party components inside compiled binaries with no labels and often no version information left to read. Build logic lives across Conan, CMake files, Bazel configs, Makefiles, Yocto recipes, and BitBake layers, and no two projects use the same way. There is a compounding problem that rarely gets named directly: which libraries are present is often not determined until build time, or until the container or environment is assembled. There is no static manifest to read. The dependency graph is only fully real once the software is built, and by then, most tools have already finished their analysis and moved on. Most tools handle this by doing their best with whatever they can find and returning results that look complete. The incompleteness tends to be silent. You get a list of components with no indication of how many were missed, and in many cases, a generous helping of components you don't actually have. When tools can't determine dependencies precisely, they guess, and those guesses show up in your inventory as findings that engineers spend time investigating before discovering the library in question was never there. The Problem Isn't Complexity. It's Assumptions. Most software composition analysis tools were designed around a reasonable assumption: that dependencies are declared somewhere machine-readable. In Python, that's a requirements file. In JavaScript, a package.json. In C and C++, that assumption fails immediately. Build systems in the C and C++ ecosystems are diverse and project-specific. CMake, Bazel, Make, Yocto, BitBake, and custom shell scripts all encode dependency logic differently, and there is no common interface for tooling to parse across them. Static linking buries third-party components inside compiled binaries, stripping the version information that scanners rely on. Libraries get copied into codebases directly, with no record of their origin and no metadata attached. Enterprise package managers like Conan exist and are improving, but they aren't a shortcut to solving this. Retrofitting an existing C/C++ project to use Conan is not a weekend task. It is an architectural undertaking that touches build infrastructure, CI pipelines, and dependency resolution logic that may have accumulated over the years. The migration cost is often far higher than the security team proposing it realizes, and the security case alone rarely wins the budget argument. Any security program that assumes package manager adoption is around the corner is building on a foundation that isn't there yet. The practical consequence is that security teams making risk decisions about their most critical software, the code that runs the kernel, the device, or the real-time system, are doing so with fundamental gaps in their data. A CVE drops for a library shipped in three products. Without accurate visibility into which builds include which version of that library, triage becomes guesswork. And because dependencies are often resolved at build time or inherited from a base container or environment, the answer to "do we use this library?" is not in a manifest. It requires someone to trace back through build logs, environment configurations, and image layers by hand. That work falls on engineers, not tooling. Start With What Shipped, Not What Was Declared The correct approach to this problem does not start with a package manager. It starts with a different question: what is actually present in this build, this artifact, this container image? This reframing matters because it accepts the reality of how C/C++ projects are actually built. Dependencies are resolved at build time. Libraries are pulled from the environment. Components are embedded in base images. The dependency graph that matters is the one that shipped, not the one that was planned, and the only way to recover it is to work backwards from the output rather than forward from what was declared. In practice, this means parsing build system outputs across all major toolchains rather than expecting a common format. It means analyzing binaries and system images alongside source trees, not instead of them. For the cases where a dependency is genuinely obscured, such as a library vendored without documentation or a component embedded deep in a third-party SDK, it means applying language-aware inference to surface what rule-based tools miss. None of this is simple. But the complexity is an argument for investing in it, not for treating C/C++ as a known unknown and moving on. What Changes When You Can Actually See The outcome of getting this right is not just a more accurate inventory. It is the CVE response measured in hours rather than days. It is compliance artifacts that reflect what is actually in production rather than what the tooling happened to find. It is AppSec teams that can answer "are we affected?" with confidence instead of a best guess followed by a week of manual investigation. C and C++ power a disproportionate share of the software that runs the world: operating systems, embedded devices, automotive systems, industrial controls, and the performance-critical cores of applications that can't afford to be wrong. Security programs that treat this code as too hard to analyze are not avoiding complexity. They are accepting risk they cannot quantify, in the software they can least afford to get wrong.

By Lexi Selldorff

Security

DZone's Featured Security Resources

Top Security Experts

The Latest Security Topics