DevSecOps and NetSecOps in the Cloud: Building Resilient Infrastructures Against Attacks in the Post-Quantum Era

30. Juli 2026

IT operations in Portugal are currently facing growing pressure on multiple fronts. Regulatory pressure has never been more tangible: NIS2, transposed into Portuguese law in 2024, DORA, in force since january 2025 for the financial sector, and the strengthening of CNCS capabilities have introduced specific obligations regarding risk management, incident reporting, and operational resilience.

At the same time, the threat landscape has intensified significantly. Ransomware attacks targeting hospitals and municipalities, combined with the sustained rise of geopolitically motivated campaigns, have turned cybersecurity into a genuine business continuity concern.

In parallel, the post-quantum cryptographic transition is no longer an academic concept. Data encrypted today using RSA or ECDH may already be collected for future decryption in a scenario commonly referred to as harvest-now-decrypt-later.

For DevOps teams in Portugal, the traditional focus on scalability and reliability must now coexist with a security posture that assumes compromise as inevitable and prepares for the next generation of cryptographic algorithms.

In this article, we explore how DevSecOps and NetSecOps converge in cloud environments, why attack resilience demands new engineering practices, and what the next four to five years may bring with the arrival of quantum networks and post-quantum cryptography in day-to-day operations.

From DevOps to DevSecOps and NetSecOps

DevSecOps emerged from the realization that treating security as a final phase in the development lifecycle is no longer sufficient. The concept of shift-left security, meaning anticipating security validation now code is written rather than immediately before deployment, has become a fundamental principle.

In practice, this means that static analysis (SAST), dependency analysis (SCA), IaC policy validation, and secrets scanning become part of the pipeline in the same way as unit testing.

On the other hand, NetSecOps represents the parallel evolution on the networking side. Traditionally, network security teams operated in silos, relying on manually managed firewalls, ACLs propagated through change requests, and VPN configurations administered via graphical interfaces.

In cloud-native environments, this model quickly becomes unsustainable. NetSecOps applies DevOps principles to network security through firewalls defined as code, programmatic microsegmentation, declarative zero trust policies enforced via APIs, and Terraform-provisioned peering and VPN configurations.

The convergence of these approaches with traditional DevOps is particularly evident in cloud environments. Platforms such as Microsoft Defender for Cloud, Google Security Command Center, and AWS Security Hub aggregate security posture signals across workloads, networks, and identities. CNAPPs (Cloud-Native Application Protection Platforms) such as Wiz, Prisma Cloud, and Lacework further consolidate this unified model.

For highly regulated Portuguese organizations, including banks, insurers, and public-sector entities, this convergence has effectively become mandatory. Audits conducted by Banco de Portugal and insurance regulators already include specific questionnaires regarding DevSecOps practices and cloud identity management.

Secure Scalability: Zero Trust and Microsegmentation

Horizontal scalability introduced a problem that many teams only discover in production. As services and instances multiply, the internal attack surface grows disproportionately.

In traditional architectures built around strong perimeters, everything inside the network is considered trusted. However, this model is extremely fragile because a single compromised entry point can enable unrestricted lateral movement.

The zero-trust model reverses this assumption. No workload, user, or device is trusted by default, regardless of network location. Every request must be authenticated, authorized, and encrypted.

In practice, this translates into:

mTLS Between Services

Ideally implemented through service mesh technologies such as Istio, Linkerd, or Cilium Service Mesh, automating certificate rotation.

Workload Identity

Based on frameworks such as SPIFFE/SPIRE, where each pod receives a verifiable cryptographic identity without relying on static credentials.

Kubernetes NetworkPolicies

Enhanced through solutions such as Cilium with eBPF support, enabling Layer 7 policies. In other words, it is no longer sufficient to define that service A can communicate with service B; communication can now be restricted to specific HTTP endpoints.

Microsegmentation

Instead of flat VPC architectures, environments become organized into isolated functional domains with explicitly defined traffic flows.

Secure scalability is based on the principle that the security posture must evolve at the same pace as the system itself, rather than degrade as the environment grows. This requires full automation, since managing hundreds of microservices through manual rules rapidly becomes impractical.

Attack Resilience: Beyond High Availability

Traditional DevOps resilience protects against technical failures such as hardware faults, deployment bugs, or network partitions. However, it does not protect against active adversaries targeting the system itself.

Attack resilience is a different discipline, with its own assumptions.

Assume Breach

The relevant questions are no longer:

• - "How quickly can we detect it?"
• - "What privileges can the attacker escalate?"
• - "Which data can be accessed?"

Recovery from Compromise

Traditional RTO (Recovery Time Objective) assumes systems can be restored from trusted backups. In ransomware scenarios, those backups may also be compromised.

Immutable backups, such as S3 object lock or Azure immutable storage, isolated in separate accounts and regularly tested for restoration become essential.

Threat Modeling as an Engineering Practice

Modern engineering requires threat modeling methodologies such as STRIDE, PASTA, and attack trees to be integrated from the system design phase onward, evolving from isolated audit exercises into continuous secure design practices.

Security Chaos Engineering

Netflix popularized Chaos Monkey as an approach for introducing controlled technical failures.

The new generation of tools, such as Chaos Mesh combined with automated purple teaming practices, extends this concept beyond operational resilience by injecting deliberate security failures, including:

• - Exposed credentials;
• - Overprivileged containers;
• - Anomalous egress patterns.

The objective is to validate detection and response mechanisms under realistic conditions.

Immutability and GitOps

Immutable infrastructures rebuilt exclusively from version-controlled sources of truth significantly improve system resilience.

Runtime changes are automatically reverted during reconciliation cycles, reducing the persistence of malicious configurations. Platforms such as Argo CD and Flux operationalize this model natively.

Incident management remains a core pillar of operational security but now also carries regulatory implications.

Under NIS2, essential and important entities must:

• - Issue an initial alert within 24 hours;
• - Provide a detailed notification within 72 hours;
• - Submit a final report within one month.

As a result, incident response runbooks must integrate not only technical procedures, but also legal workflows, institutional communication, and reporting obligations to competent authorities.

Security Automation and Policy as Code

If Infrastructure as Code (IaC) democratized infrastructure provisioning, the Policy as Code model democratized governance and compliance. The principle is based on transforming security controls, CIS benchmarks, ISO 27001 requirements, and internal policies into code that is automatically validated throughout development pipelines and deployment stages.

Security therefore becomes verifiable, auditable, and continuous.

Open Policy Agent (OPA)

Open Policy Agent, through the Rego language, has become a de facto standard for policy validation in cloud-native environments. It is widely used in Kubernetes through integrations such as Gatekeeper and can also be applied to Terraform pipelines, enabling security controls before resource provisioning.

Checkov, tfsec e KICS

Tools such as Checkov, tfsec, and KICS perform static analysis of IaC configurations, detecting insecure settings before deployment.

Among the most common issues are:

• - Public S3 buckets;
• - Excessively permissive security groups (0.0.0.0/0);
• - Disabled encryption at rest.

Sentinel

Sentinel is the proprietary alternative integrated into Terraform Cloud and Terraform Enterprise, enabling policies to be enforced directly within infrastructure execution workflows.

Secrets management remains one of the most critical pillars of operational security.

Secrets embedded directly into source code continue to be among the leading causes of cloud environment compromise.

Detection tools such as Gitleaks, TruffleHog, and GitGuardian should be executed both during pre-commit stages and throughout CI pipelines.

At runtime, solutions such as HashiCorp Vault, Azure Key Vault, AWS Secrets Manager, and GCP Secret Manager centralize the secrets lifecycle, supporting:

• - Automatic rotation;
• - Audit trails;
• - Integration with workload identities.

IAM management as code, including roles, policies, and trust relationships, should follow the same rigorous review and continuous integration standards applied to application code.

The principle of least privilege is no longer just a theoretical recommendation. It is increasingly enforced systematically through tools such as AWS Access Analyzer and CIEM (Cloud Infrastructure Entitlement Management) solutions capable of identifying unused permissions and recommending their reduction.

Secure CI/CD: The Supply Chain as an Attack Vector

The major incidents of the last decade, including SolarWinds, dependency confusion, Log4Shell, and the XZ Utils backdoor, share a common pattern: attackers did not compromise the final target directly, but rather something the target trusted and relied upon. This transformed software supply chain security into a strategic priority across the industry.

Over time, several best practices have become established.

Mandatory SBOM

Software Bill of Materials (SBOM) files, in formats such as SPDX or CycloneDX, should be generated with every build, describing all direct and transitive dependencies.

For organizations covered by NIS2 and public-sector suppliers, this practice is already starting to emerge as a contractual requirement.

Artifact Signing

Tools such as Sigstore (cosign, fulcio, rekor) have made container image and artifact signing practically trivial.

Admission validation mechanisms, using solutions such as Kyverno or Connaisseur, ensure that only artifacts signed by trusted keys are allowed into production environments.

in-toto / SLSA Attestations

The SLSA (Supply-chain Levels for Software Artifacts) framework defines progressive assurance levels regarding how software artifacts are built.

SLSA 3, based on builds executed in protected environments with verifiable provenance, is currently considered a realistic target for many organizations over the next two to three years.

Reproducible Builds

The same input should always produce the exact same output, byte for byte. This enables independent verification and helps detect tampering within the toolchain.

Continuous Vulnerability Scanning

Container images and application dependencies should be continuously scanned using tools such as Trivy, Grype, and Snyk, prioritizing vulnerabilities based on real exploitation likelihood through metrics such as EPSS and KEV catalogs, rather than relying exclusively on CVSS scores.

Build Isolation

Ephemeral runners, without persistent secrets and without lateral access to production networks.

For Portuguese financial institutions operating under DORA, ICT supply chain control has evolved from a best practice into a direct regulatory obligation. SBOM and attestation practices contribute directly to compliance requirements.

Unified Observability: SOC, DevSecOps and AIOps

The traditional separation between operations teams - focused on Grafana, Prometheus, and latency dashboards - and security operations teams - focused on SIEM platforms, detection rules, and SOC alerts - no longer withstands modern operational realities.

A latency spike may result from a poorly executed deployment or an ongoing DDoS attack. An increase in 401 errors may indicate a token renewal bug or a credential stuffing attempt.

Unified telemetry has become the most rational response.

Cloud-Native SIEM

Platforms such as Microsoft Sentinel, Google Chronicle, Wazuh (open source), and Elastic Security enable log ingestion, event correlation, and detection rules defined as code through Sigma rules.

SOAR

For automated response workflows, playbooks can isolate a host, revoke a token, create a ticket, notify responsible teams, and execute all these actions within seconds.

Runtime Detection

Kernel-level observability through eBPF enables the detection of anomalous container behavior, such as unexpected shell execution; binding to undeclared ports and access to sensitive files.

AIOps Applied to Security

Behavioral detection models (UEBA), automatic correlation of scattered alerts, and false-positive reduction through supervised classification are becoming increasingly operationally mature.

Large language models are also beginning to be used to summarize alerts and suggest initial hypotheses to analysts.

In more mature organizations, unified dashboards already combine SLO metrics with security indicators such as:

• - Failed authentication attempt rates;
• - Baseline deviations;
• - Age of non-rotated credentials.

SRE and security teams increasingly operate over the same observability layer, even when using different data sources.

The Next 4-5 Years: Post-Quantum Cryptography and Quantum Networks

This is precisely where IT planning in Portugal must begin looking beyond short-term operational horizons. Two parallel technological evolutions are expected to significantly impact how infrastructures are designed and operated over the next four to five years.

Post-Quantum Migration (PQC)

In August 2024, NIST published the first finalized post-quantum cryptography standards:

Formerly known as CRYSTALS-Kyber, designed for key encapsulation and intended as a replacement for RSA-KEM and ECDH.

FIPS 204 (ML-DSA)

Formerly CRYSTALS-Dilithium, focused on digital signatures.

FIPS 205 (SLH-DSA)

Formerly SPHINCS+, a hash-based signature model designed as a more conservative alternative.

These algorithms were developed to resist both classical computers and sufficiently advanced quantum computers capable of executing Shor’s algorithm. Although the arrival of such systems remains uncertain, with estimates ranging from 5 to 25 years, preparation cannot wait for definitive confirmation.

The harvest-now-decrypt-later risk is already considered real. TLS traffic intercepted today, with key exchanges based on ECDHE, may be stored and decrypted in the future once quantum computing capabilities reach sufficient maturity.

For highly sensitive data such as medical records, government information, critical intellectual property and long-term financial data, the exposure window has already begun.

Likely scenarios for the Portuguese cloud ecosystem over the next 4-5 years include:

Hybrid TLS 1.3 (X25519 + ML-KEM-768) begins to become standard across modern stacks.

OpenSSL 3.5, BoringSSL, rustls, and most AWS, Azure, and GCP load balancers already provide support.

PQC cipher suites also begin appearing in automated audit pipelines through tools such as: testssl.sh and sslyze.

CNCS, aligned with ENISA guidelines, and Banco de Portugal, working alongside the ECB and EBA, begin publishing concrete guidance regarding crypto-agility and migration roadmaps for critical infrastructures.

DORA audits gradually begin including cryptographic inventories.

Corporate VPNs (IKEv2 with PQC KEMs), SSH implementations (OpenSSH already includes experimental support in version 9.x), and signed code using Dilithium signatures in internal PKIs begin large-scale migration processes.

Internal mTLS infrastructures, workload certificates, and corporate PKIs increasingly become part of multi-year migration strategies.

2029-2030

PQC adoption becomes practically mandatory across regulated sectors.

Organizations that fail to begin cryptographic inventories before 2026 may face reactive migration processes driven by regulatory pressure.

Practical implications for IT operations include:

Organizations must identify where RSA, ECDSA, DSA, and ECDH are currently used:

• - Application code;
• - IaC;
• - Certificates;
• - SSH keys;
• - KMS-managed secrets;
• - Third-party integrations.

Tools such as CryptoNext, ISARA, or custom approaches using nmap and TLS parsing become especially relevant.

Cryptographic dependencies must remain configurable rather than hardcoded.

Many organizations took years to migrate away from SHA-1 precisely because algorithms were rigidly embedded into applications.

New cryptographic primitives introduce direct operational impacts.

For example:

• - A Kyber-768 public key is approximately 1184 bytes;
• - An RSA-2048 key occupies roughly 256 bytes;
• - Dilithium-3 signatures approach 3300 bytes.

This directly affects:

• - Handshake sizes;
• - MTU;
• - Latency;
• - Overhead in high frequency mTLS environments.

Organizations must closely monitor vendor roadmaps from: Thales, Utimaco, AWS CloudHSM, Azure Managed HSM and Google Cloud HSM.

PQC support in HSMs is still in the early stages of adoption.

Teams maintaining proprietary software must define structured adoption roadmaps. Projects such as liboqs and the OQS Provider for OpenSSL 3.x are increasingly becoming important interoperability references.

Quantum Networks: EuroQCI and the QKD Use Case

In parallel, the concept of quantum networks introduces a fundamentally different approach to cryptographic key distribution.

Quantum Key Distribution (QKD) uses the physical properties of quantum mechanics to distribute keys. Any interception attempt introduces detectable alterations due to the uncertainty principle.

Security guarantees therefore no longer depend exclusively on computational difficulty but instead become information theoretic.

Portugal is currently participating in the EuroQCI (European Quantum Communication Infrastructure) initiative through the Iberian segment IberQCI, connecting Portugal and Spain.

Pilot projects in Lisbon, involving organizations such as IT, INESC TEC, telecommunications operators and financial institutions are expected to materialize over the coming years.

A realistic timeline may include:

2026-2027

QKD pilots between selected data center pairs in the Lisbon metropolitan area using dedicated dark fiber connections.

Use cases include:

• - Connectivity between core banking systems and disaster recovery sites;
• - Connections between primary datacenters and escrow systems.

2027-2028

Hybrid integration between QKD and PQC in critical environments. QKD distributes symmetric keys that are subsequently used in symmetric encryption systems such as AES-256, while PQC provides fallback mechanisms and authentication layers.

2028-2030

Expansion toward intercity connections through trusted nodes, potentially complemented by satellite-based QKD initiatives under EuroQCI Space programs.

Adoption is expected to remain concentrated in highly sensitive sectors such as: Defense, Large-scale banking and critical infrastructure environment.

For most IT teams in Portugal, QKD will likely remain a niche technology throughout this period.

The practical priority over the coming years will clearly be PQC adoption in software rather than QKD deployment over fiber infrastructure.

Nevertheless, organizations operating in critical sectors should closely monitor these pilots, develop internal expertise, and understand where QKD may complement broader post-quantum migration strategies.

What to Do Over the Next 12-24 Months

For IT operations teams in Portugal, the most important step is to begin a gradual and realistic transition process.

Cryptographic Inventory

Automate discovery across: IaC, source code and runtime environments. Without a proper inventory, no migration strategy can be considered credible.

Update Threat Models

Include harvest-now-decrypt-later scenarios and identify data requiring protection periods longer than 10 years.

Pilot PQC in Non-Production Environments

Test: hybrid TLS endpoints, image signing using experimental Dilithium integrations with cosign anda SSH using post-quantum algorithms.

Technical Training

This will likely become the largest cryptographic transition since the deprecation of SHA-1 and requires expertise that remains relatively scarce in the market.

Monitor Cloud Providers

PQC roadmaps published by AWS (KMS), Azure (Key Vault), and GCP (Cloud KMS) will play a decisive role in accelerating adoption.

Follow Regulatory Developments

Guidance issued by CNCS, ENISA, BCE, Banco de Portugal and ANACOM will become progressively more relevant.

Although NIS2 and DORA do not yet explicitly mandate PQC adoption, crypto-agility requirements are expected to increasingly emerge during audits.

For Critical Sectors

Closely follow initiatives led by FCT, INESC, IT and operators involved in IberQCI. The objective is to understand timelines, pilot opportunities, and future integration possibilities.

Best Practices: A Summary for IT Operations

Shift-Left and Shift-Right Security

Security integrated from the beginning (pull requests, IaC, SBOM) and continuously monitored at runtime through (eBPF, behavioral anomaly detection, SOC telemetry).

Crypto-Agility as a Principle

Cryptographic algorithms should be treated as replaceable components: configurable; monitorable and reversible.

The migration from SHA-1 to SHA-256 was a warning. PQC will be the real test.

Operational Zero Trust

Identity becomes the perimeter, with mTLS enabled by default between services, automated microsegmentation and systematic enforcement of least privilege principles.

Supply Chain as a Critical Control

SBOM generation, signing, attestations, and build isolation are no longer optional best practices.

They are increasingly becoming critical requirements for organizations covered by NIS2 and DORA.

Unified Observability

Ops and SecOps teams increasingly share telemetry, tooling and operational context.

At the same time, AIOps is beginning to play a significant role in noise reduction and automatic correlation of scattered signals.

The next generation of IT infrastructures in Portugal will not distinguish itself solely through workload scalability or sophisticated dashboards, but rather through the ability to assume compromise, recover with integrity, and migrate cryptography without disrupting operational continuity.

DevSecOps and NetSecOps represent the discipline. The post-quantum transition will be the real test of the coming years.