Tag: software vulnerabilities

  • The Breakneck Future of Codegen: Why AI SWE Must Be Matched with AI SRE 

    The Breakneck Future of Codegen: Why AI SWE Must Be Matched with AI SRE 

    AI-driven code generation is transforming how software is built — accelerating development and expanding what engineers can create. But as speed and scale increase, so do complexity and fragility. Systems grow denser, and small configuration errors can cascade into major outages. Early research links AI-generated code to higher duplication and vulnerability rates, underscoring the need for new approaches to reliability. 

    Engineers are already maintaining systems they don’t fully understand — and AI is only amplifying this trend. AI site reliability engineers (AI SREs) will be needed to reason across massive observability data and use parallel search architectures that can test causal hypotheses simultaneously rather than iteratively. This shift toward distributed, concurrent reasoning will be essential to keep modern software resilient as AI reshapes how it’s built. 

    The Promise of AI Codegen 

    AI code generation marks one of the most significant shifts in modern engineering — unlocking speed, creativity, and access in ways the industry hasn’t seen before. Engineers can scaffold microservices, generate Kubernetes manifests, and deploy applications in minutes — tasks that once took days or weeks. 

    With models like GitHub Copilot and Claude producing production-ready code, teams are shipping more features, exploring new areas of the stack, and compressing time-to-market cycles dramatically. 

    The Double-Edged Nature of Velocity 

    As development accelerates, complexity multiplies and human context erodes. Each generated service adds configuration files, dependencies, and telemetry — compounding system density and interdependence. 

    Engineers are also expected to ship faster than ever, leaving less time to understand what they’re deploying. AI codegen blurs traditional boundaries: software developers modify infrastructure, and infrastructure engineers tweak application logic. This flexibility increases throughput but introduces comprehension debt — neither side holds full context across the stack. Over time, systems become opaque. When incidents occur, the question is no longer just “what broke?” but “why was it built this way?” 

    Keeping Systems Online was Hard Enough Already 

    The 2024 CrowdStrike outage showed how fragile large-scale systems can be. A single misconfigured update cascaded globally within minutes, grounding airlines and halting commerce. That same pattern has played out before — like in 2021, when a BGP misconfiguration at Meta removed Facebook, WhatsApp, and Instagram from the internet for six hours. 

    Those incidents occurred before AI began generating production infrastructure at scale. As AI-driven automation expands, similar failures could become more frequent and harder to trace. A single misgenerated network policy, Helm chart, or service mesh rule can ripple across dozens of services. These configurations often appear correct but hide subtle flaws — mis-specified resource limits, deprecated API versions, or over-permissive roles. 

    Meanwhile, observability systems are ingesting unprecedented volumes of logs, metrics, and traces, stretching even the most seasoned SRE teams to their limits. 

    Data Points to Growing Fragility 

    Research already shows that the tradeoff between speed and reliability is emerging. For example: 

    • GitClear (2024): Duplicate code blocks increased fourfold as AI adoption rose (with some analyses reporting higher), while refactored or reused code declined. 
    • Veracode (2025): Nearly half of AI-generated samples failed basic security checks in pre-production testing. 

    The pattern is clear: AI codegen accelerates development but also magnifies technical debt. Code may compile and deploy — but its long-term reliability, observability, and resilience are far from guaranteed. 

    When Human Context Isn’t Enough 

    During incidents, engineers often face failures in code they didn’t write and infrastructure they didn’t configure. The traditional SRE model assumes deep system understanding — an assumption that breaks when AI-generated components interact in unpredictable ways. Manual debugging, driven by iterative queries and dashboards, cannot keep up with modern failure modes. 

    The challenge isn’t that today’s site reliability engineers (SREs) aren’t doing their jobs — it’s that the job itself is about to outgrow what any human team can manage unaided. 

    The Rise of the AI SRE 

    To fully realize the promise of AI codegen, reliability must evolve in parallel. The next step is the AI SRE — systems capable of reasoning across massive data volumes to restore lost context. 

    An AI SRE can parse logs, metrics, traces, and deployment histories to reconstruct system behavior in real time. It can correlate anomalies, identify causal chains, and surface hypotheses in minutes that would take human teams hours to form. 

    If AI is going to write and deploy code, it must also help monitor and stabilize it. The rise of the AI software engineer demands an equally capable counterpart on the reliability side — one that can distinguish correlation from causation and manage complexity at enterprise scale. 

    Why Parallelism Matters 

    Not all AI SREs reason the same way. Some work iteratively — forming one hypothesis at a time and refining it as new data arrives. That approach can handle localized issues but breaks down in large, interdependent systems. 

    Parallel search scales better. It allows multiple investigative threads — or agents — to reason concurrently, each exploring a different subsystem or hypothesis before merging results into a shared context. In practice, this looks like distributed inference: several reasoning paths run in parallel, exchanging intermediate signals to converge on the most plausible causal chain. 

    By reasoning in parallel, AI SREs can handle the scale and heterogeneity of modern production systems while engineers stay focused on prevention and long-term resilience. 

    The Road Ahead 

    AI codegen is accelerating software development at an unprecedented pace — but speed without reliability breeds fragility. To sustain this momentum, innovation in AI for reliability must advance alongside AI for creation. AI may be building the future of software, but it will take equally intelligent systems — working alongside today’s engineers — to keep that future reliable. 

    KubeCon + CloudNativeCon North America 2025 is taking place in Atlanta, Georgia, from November 10 to 13. Register now. 

     

  • Survey: Cyberattacks Aimed at Software Supply Chains are Pervasive

    Survey: Cyberattacks Aimed at Software Supply Chains are Pervasive

    A survey published today finds 91% of respondents work for organizations that have experienced a software supply chain incident in the past 12 months.

    The survey polled 368 IT, cybersecurity and application developer professionals responsible for application security in North America and was conducted by the research firm Enterprise Strategy Group (ESG) on behalf of Data Theorem, a provider of an application security platform. The survey found zero-day exploits of vulnerabilities within third-party code (41%) were the most common attack vector, followed closely by misconfigured cloud services (40%), vulnerabilities in open-source software and container images (40%), stolen secrets/token/passwords (37%) and breaches of application programming interfaces (APIs) (35%).

    The biggest areas of impact of those breaches are identified as cryptojacking (43%), inability to meet service level agreements (41%), malware infestation (39%), unauthorized access (39%), stolen developer credentials (37%), data loss (37%) and the levying of fines (37%).

    Despite these issues, however, nearly three-quarters (74%) of respondents claimed their organization has “robust” software supply chain security capabilities even though a similar percentage said they are making significant investments in software supply chain security, with an additional 25% making moderate investments. More than three-quarters (77%) said they have increased their effort to secure third-party software components and container images in the wake of an attack. The top two areas of focus are new detection rules/analytics (33%) and the adoption of multifactor authentication (MFA) (33%).

    Top investment priorities over the next 12 to 18 months include scanning open source code components and third-party libraries for vulnerabilities (44%), followed by discovering and inspecting APIs in source code (39%), using composition analysis tools to create software bill of materials (SBOMs) (38%) and applying runtime API security controls (33%).

    The most widely used tools today are automated open source package risk management (34%), static application security testing (SAST) tools (34%), vulnerability scanning of cloud services (32%), automated security as code policy enforcement (31%) and dynamic application security testing (DAST) tools (31%).

    Data Theorem COO Doug Dooley said while the survey makes it clear progress is being made, there is still a lack of urgency. It may require additional high-profile breaches to create a large enough public outcry to pass the legislation that is going to be required to address software supply chain security issues more vigorously. In fact, 83% of respondents noted industry regulations are a key driver to ensure they create accurate SBOMs.

    In general, the survey finds nearly two-thirds of respondents (65%) have more than 50 Git repositories, with 40% reporting that more than half of their code is composed of third-party software. Half of respondents (50%) said they expected that to rise to more than half in the next 12 months. Well over half (58%) noted more than 30% of their code would be of open source software.

    Only 43% report they are completely confident that their developers are only using secure open source software. On the plus side, 90% are prioritizing efforts to shift security left to developers.

    Overall, 86% said it’s critical or important to know the composition/inventory of application code in use, where code is stored, and who has access to code components connected to their code. A total of 88% also noted it’s critical or important to have accurate inventory of their third-party APIs and cloud services.

    The one thing that is certain in the months ahead is that cybercriminals will put software supply chain security to the test. The challenge and the opportunity now, regardless of what regulations are ultimately passed, is to thwart those attacks before the damage inflicted ultimately forces lawmakers to act in ways that make software development a lot more difficult than it already is.

  • Top 10 Common Software Vulnerabilities

    Top 10 Common Software Vulnerabilities

    An essential part of an effective software security process is being familiar with software vulnerabilities, which are flaws or weaknesses in your code. Often, testing and manual code reviews are unable to identify every single vulnerability, which can impact the performance and security of your software. For that reason, it is important to have a working understanding of software vulnerabilities as it will enable you to more effectively manage potential security threats.

    The top 10 most common security vulnerabilities are as follows:

    1. Insufficient Logging and Monitoring: Insufficient logging and monitoring process are dangerous as they leave your data vulnerable to tampering, extraction, or even destruction.
    2. Injection Flaws: Injection flaws can trick the targeted system into executing unintended commands as well as provide untrustworthy agents access to protected data.
    3. Sensitive Data Exposure: Sensitive data—which includes addresses, passwords and account numbers—must be adequately protected against human-error and security breaches to avoid potential exposures.
    4. Using Components with Known Vulnerabilities: Components—which are made up of libraries, frameworks and other software modules—are often run on the same privileges as your application. Which means if a component is vulnerable, those weaknesses can be exploited in an effort to access your application.
    5. Cross-Site Scripting (XSS) Flaws: Cross-site scripting flaws can be exploited by untrustworthy agents in an effort to execute their own scripts in your system.
    6. Broken Authentication: If authentication and session management application functions are implemented incorrectly, a software vulnerability can be created.
    7. Broken Access Control: If user restrictions are broken, it can create a software vulnerability that can be exploited.
    8. XML External Entities (XXE): In order to properly understand an XML data, an XML parser is necessary. However, if the parser is poorly configured and the XML input that contains a reference to an external entity, it can provide a flaw that an untrustworthy agent can exploit.
    9. Security Misconfiguration: Security misconfigurations are often brought upon for numerous reasons, including: insecure default configurations, incomplete or impromptu configurations, open cloud storage, misconfigured HTTP headers and wordy error messages that contain sensitive information.
    10. Insecure Deserialization: Deserialization flaws often result in remote code executions, which enables untrustworthy agents to perform replay, injection and privilege escalation attacks.

    Prevent Software Vulnerabilities

    In order to efficiently and effectively prevent software vulnerabilities, we recommend the following best practices:

    • Establish software design requirements.
    • Use a coding standard.
    • Test your software.

    To read more, please visit: https://www.perforce.com/blog/kw/common-software-vulnerabilities