The Software Efficiency Report · From the Founder's Desk
The Software Efficiency Report | 2026 Week 31
Software Composition Analysis Is Now a Leadership Issue
Welcome to this week’s edition of The Software Efficiency Report. Plenty happened across software engineering. The shrinking window between vulnerability discovery and exploitation stands out. We also ask whether AI-assisted coding is improving real software delivery and share a practical tip for keeping development environments reproducible.
The trends cover the EU Cyber Resilience Act, modernization agents, MCP, digital twins, edge AI, cloud oversight, embedded Linux delivery and forward-deployed engineering. We also look at what changes when AI agents become users of internal platforms.
The main article examines SCA, SBOMs, vulnerabilities, open-source licences and the European legal changes making them leadership concerns. The report closes with useful tools and communities, followed by selected cloud, open-source, DevOps, security, AI/ML, embedded systems and IoT news.
- Metric of the week
- Mean Time to Exploit: -7 Days
- Deep dive
- Software Composition Analysis Is Now a Leadership Issue
Software Efficiency Metric of the Week
Mean Time to Exploit: -7 Days
The traditional patching window has almost disappeared. Mandiant estimates that the average time to exploit a vulnerability fell from 63 days in 2018 to minus seven days in 2025. This means exploitation is often happening before a patch is available.
A 30-day patching SLA alone is no longer enough. Teams need accurate asset inventories, threat-based prioritization, runtime detection, compensating controls and pre-approved isolation procedures while patches are tested and deployed.
In my experience, teams get better results by combining SBOMs, EPSS, CISA’s Known Exploited Vulnerabilities catalogue, automated patch pipelines and tested rollback procedures, instead of measuring security performance only by the number of vulnerabilities closed. More details:Source Source Source
Reader Poll
Has AI-assisted coding actually improved your software delivery?
My take: Faster code generation does not automatically mean faster delivery. AI may simply move the bottleneck into review, testing, security or release management. Teams should measure PR cycle time, escaped defects, change failure rate, recovery time and developer experience, not lines of code or prompt usage. Source Source Source
Where is your team today?
A) No measurable improvement yet B) Coding is faster, but review or testing takes longer C) End-to-end delivery is faster, with quality remaining stable D) Delivery speed, reliability and business outcomes have all improved
What has AI actually changed for your team?
Engineering Tip of the Week
Make the development environment reproducible. Commit a devcontainer.json, pinned toolchain versions, setup scripts and required local services with the code. Reuse the same bootstrap and validation commands in CI. New developers and coding agents can start quickly, while environment drift and “works on my machine” failures are reduced. :Source Source
Technology Ecosystem Trends
Ten Developments/Trends picks for this week Shaping Modern Engineering Operations
- The EU Cyber Resilience Act is becoming an operational deadline: New guidance arrived on 27 July, ahead of vulnerability and incident reporting rules taking effect on 11 September 2026; affected companies now need clear product ownership, PSIRT processes, SBOM records and tested 24-hour and 72-hour reporting workflows. Source Source
- Legacy modernization agents are becoming technology-specific. New workflows target IBM Z, IBM i, Java and mainframe applications instead of offering generic code generation; operational success still depends on dependency mapping, regression baselines and expert approval. Source Source.
- MCP is becoming easier to operate at enterprise scale. The July 28 specification introduces a stateless core, long-running tasks, an extension framework and stronger authorization, reducing the need for sticky sessions and shared session storage.:Source.
- Digital-twin models are becoming portable engineering assets. OCI IoT Platform uses DTDL v3 to describe device properties, telemetry and relationships, encouraging teams to version twin schemas alongside firmware and backend APIs. :Source.
- Edge AI is becoming part of mainstream embedded platforms. Microchip’s planned acquisition of Hailo combines embedded processors, FPGAs and connectivity with vision SoCs and AI accelerators, pointing toward integrated toolchains for robotics, cameras, industrial automation and intelligent devices. Source.
- Major cloud providers are now treated as systemic financial infrastructure. UK regulators designated AWS, Microsoft, Google Cloud and Oracle as critical third parties, bringing resilience testing, incident reporting and regulatory oversight directly to cloud providers. Source
- Security agents are moving from detection to validated remediation. Google’s CodeMender preview can test whether a vulnerability is exploitable and propose a tested code fix, although human review should remain mandatory before merging changes.Source.
- Embedded Linux delivery is adopting mainstream DevSecOps practices: The July release of Yocto Project 6.0.2 included maintenance and security updates, reinforcing the need for automated layer upgrades, reproducible builds, SBOM and CVE checks, QEMU or hardware regression testing, and safe OTA rollback. :Source Source
- Forward-deployed engineering is becoming a major AI delivery model: AWS committed $1 billion to engineers embedded with customers, while TCS plans a team of up to 8,900 forward-deployed engineers; buyers increasingly expect consultants to deliver working production systems, transfer knowledge and leave the internal team able to operate them. :Source Source
- Internal platforms must now support AI agents as users: July CNCF discussions describe platforms serving developers, SREs and agents through the same operational model, which means agent identities, scoped permissions, audit trails, cost controls and reliable service context must become standard platform capabilities. :Source ,Source
Deep Dive Article – Software Composition Analysis Is Now a Leadership Issue
A critical vulnerability is announced in the morning. Within a few hours, one of your enterprise customers asks whether your product is affected.
The security team starts checking vulnerability databases. Developers search the source repositories. DevOps checks the container images. Someone contacts the software supplier. By the end of the day, there is still no complete answer.
After working in IT for around 25 years, I have seen this situation in different forms. Most companies have improved a lot in building and releasing software. But many still cannot clearly say what is inside the product they already shipped.
This sounds like a technical question. It is also becoming a business, customer and regulatory question.
Why this matters now
The EU Cyber Resilience Act entered into force on 10 December 2024.
Its vulnerability-reporting obligations apply from 11 September 2026. The main obligations will apply from 11 December 2027.
The Act applies to many software and hardware products with digital elements made available in the European Union. The exact scope and exclusions need to be reviewed for each product.
From September 2026, manufacturers covered by the Act may need to provide an early warning within 24 hours after becoming aware of an actively exploited vulnerability or severe security incident. A more detailed notification may be required within 72 hours.
Some areas of non-compliance can result in administrative fines of up to EUR 15 million or 2.5 percent of worldwide annual turnover, whichever is higher.
For a CTO, VP or engineering director, this is not something to leave with the security team just before the deadline.
If the organisation cannot connect a vulnerable component to its products, released versions and customers, most of the first 24 hours may be spent only trying to understand what is affected.
Most software contains more external code than internal code
Modern products are built using open-source libraries, frameworks, SDKs, container images, operating system packages and components supplied by vendors.
A development team may directly select 50 packages. Those packages can bring hundreds of other dependencies.
The same issue exists in embedded products. A firmware image may contain Linux packages, cryptographic libraries, utilities, drivers and vendor SDKs. Many of these may be introduced by the build system and not directly by the application developer.
This is where Software Composition Analysis, normally called SCA, becomes useful.
SCA helps identify open-source and third-party components used inside a product. It can show component versions, known vulnerabilities, dependency relationships, available upgrades and the licences connected with those components.
It gives the organisation a better view of what it is actually delivering.
Commercial and open-source tools
There are both commercial and open-source options for SCA and SBOM management.
Commercial platforms such as Black Duck, Mend, Snyk and Sonatype Lifecycle provide component analysis, licence governance, policy enforcement, vulnerability information and enterprise reporting.
Black Duck is one of the established platforms in this area. Even though I have even personally used this while working for companies, I know it is very expensive. It is commonly used by larger organisations where licence compliance, central policies, audit reports and product governance are important.
Open-source tools can also provide a good starting point. Syft can generate Software Bills of Materials. Trivy and Grype can scan containers, operating system packages and application dependencies. OWASP Dependency-Check can identify known vulnerable dependencies. Dependency-Track can consume SBOMs and continuously monitor component risk.
The right choice depends on the product, engineering scale, regulatory exposure and how much central governance is required.
I would not start by comparing tool features.
First decide what risks should block a release, who owns the finding, who can approve an exception and how quickly the company needs to respond. After this, selecting the tool becomes much easier.
A scanner can identify the risk. It cannot take ownership of it.
The Software Bill of Materials
A Software Bill of Materials, or SBOM, is a machine-readable inventory of components inside a software product.
SPDX and CycloneDX are the formats most teams will come across.
An SBOM can include the component name, version, supplier, package identifier, file hash, dependency relationships and licence information.
The Cyber Resilience Act requires manufacturers within its scope to identify and document components and vulnerabilities. It refers specifically to creating an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies.
For practical security work, top-level dependencies alone may not be enough.
Many serious vulnerabilities are found several levels down in the dependency chain. The development team may not even know that the affected package is being used.
An SBOM should also represent the actual product released to customers.
Generating it only from the source repository can miss packages added during the build. Container base images and operating system layers may bring additional components. In embedded systems, the final firmware image may contain many packages not visible in the main application repository.
Where possible, generate the SBOM from the final application package, container image or firmware artifact. Store it with that release and keep the relationship between the product version, build and SBOM.
An SBOM does not prove that the product is secure. It provides the inventory required to make a proper decision.
Also, the Cyber Resilience Act does not simply say every SBOM must be published openly. How it is shared, stored and provided to authorities or customers needs to be decided carefully.
Licence risk is also part of the problem
The Cyber Resilience Act mainly focuses on cybersecurity. It is not an open-source licence law.
Still, the component information collected by SCA can also support licence compliance.
Open-source software is free to use under the conditions of its licence. Those conditions are not the same for every component.
Licences such as MIT, BSD and Apache are generally easier to use in commercial products. Even these may require copyright notices, attribution or licence text to be included.
GPL, LGPL and AGPL can create additional obligations depending on how the software is modified, linked, distributed or provided as a service.
There are also components available under both open-source and commercial licences. The organisation should know which option it is using and what obligations comes with it.
A licence which is acceptable for an internal tool may not be acceptable for a commercial SaaS product, mobile application or firmware shipped inside a device.
Finding this issue just before release can be expensive. The engineering team may need to replace the component, rebuild part of the product, prepare missing notices or purchase a commercial licence.
It can also delay a customer security review, investment activity or acquisition due diligence.
Developers should not have to make these legal interpretations alone.
Engineering, security, product and legal teams need a simple policy. Some licences can be approved. Some need review. Others may be restricted for certain product types.
Tools such as Black Duck can apply these policies when the component is introduced, rather than discovering the problem at the end of the release. Black Duck provides three types of findings: operational risks, security vulnerabilities, and license compliance issues
Installing a scanner is not the end
I have seen companies successfully run SCA tools in every pipeline and still struggle with software component risk.
The scanner may be working correctly. But nobody owns the findings. Thousands of vulnerabilities are reported. Developers cannot understand which ones are exploitable. Exceptions are approved and never reviewed again. Older product versions remain with customers, but no team is clearly responsible for maintaining the dependencies.
This produces reports, but not much risk reduction.
The organisation needs a process to separate urgent issues from normal maintenance work. It also needs evidence when a reported vulnerability does not affect the product.
VEX, which stands for Vulnerability Exploitability eXchange, can help document whether a vulnerability is applicable to a specific product.
For example, the vulnerable function may not be enabled or reachable. But such a decision should have technical evidence and a responsible owner. Writing “not exploitable” in a spreadsheet is not sufficient.
The product-liability side is changing too
The EU’s updated Product Liability Directive recognises software as a product for liability purposes.
This includes operating systems, firmware, applications, AI systems and software provided using cloud or SaaS models.
The Directive also recognises that a cybersecurity vulnerability can be relevant when deciding whether a product is defective.
EU member states must transpose it into national law by 9 December 2026. The updated rules apply to products placed on the market or put into service from that date.
This does not mean every vulnerability will create legal liability. But it does show the direction software product responsibility is moving.
Companies may need to show what was inside a product, how security risks were assessed, how long the product was supported and what action was taken after a vulnerability became known.
That evidence has to come from the engineering and delivery process. Rebuilding it after an incident will be difficult and sometimes impossible.
A useful question for leadership
If a critical open-source vulnerability is announced tomorrow, can your organisation identify every affected product within 24 hours?
Can the team identify the versions already delivered to customers?
Is there an accurate SBOM for each release?
Who owns the vulnerability after the scanner finds it?
Are licence issues checked when a dependency is added, or only before the release?
Can the organisation provide an evidence-based response to a customer or regulator?
If the answer need three teams, several spreadsheets and a full day of investigation, there is a gap to address.
Where I would begin
Start with the products already supported in the market.
Generate an SBOM for each released product and check whether it really matches the artifact delivered to customers. Define vulnerability and licence policies. Give every finding and exception an owner. Exceptions should include a reason, approver and expiry date.
Run SCA when developers add dependencies. Scan the final artifact again during the build. Keep the SBOM with the release evidence and continue monitoring after the product is deployed.
Then test the process with a small exercise.
Select one component used across several products. Assume that a critical vulnerability has been reported. See how long it takes to identify the products, versions, owners and affected customers. Try preparing the first response within 24 hours. This exercise normally finds the real gaps much faster than another long policy document.
Software Composition Analysis and SBOM management is now connected with engineering, DevOps, product security, legal and product management.
The European law changes are making it urgent. Customers are also asking more questions about software supply chains, component security and open-source licences.
Tools, Resources and Communities | Worth Knowing
Open Source Tools
- KEDA: A lightweight Kubernetes autoscaler that scales workloads from queues, events and operational metrics, including scale-to-zero.:Source
- OpenBao: An open source secrets-management platform for credentials, certificates and encryption keys, with community-led governance through OpenSSF. :Source
- Zephyr RTOS: A fast-growing Linux Foundation ecosystem for secure embedded and IoT development, now supporting more than 1,000 hardware boards. :Source
Commercial Tools
- Port: A growing internal developer portal platform for software catalogs, golden paths, self-service operations and engineering governance. Source
- Black Duck SCA: Particularly relevant for SBOM generation, open source vulnerability management, licence compliance and preparation for regulations such as the EU Cyber Resilience Act. Source
- Cortex: An engineering operations and internal developer portal platform focused on service ownership, scorecards, production readiness and golden paths. Source
Learning and Community
- LF Edge A useful Linux Foundation community for edge computing, industrial IoT, connected devices and AI deployment outside central cloud environments. Source
- LF AI & Data A vendor-neutral community supporting open source AI, data infrastructure, model formats and enterprise AI standards.Source
- SRE Weekly A consistently useful newsletter covering reliability engineering, incident response, scalability, automation and production operations. Source
- Eclipse IoT A strong community for industrial IoT, device connectivity, edge runtimes and open source embedded development.Source
- Yocto Project Community Worth following for reproducible embedded Linux distributions, board-support layers and long-term device software maintenance.Source
Technology Ecosystem Weekly News Digest – Top Picks
Cloud and Platform Updates
- AWS latest updates: AWS focused on Day 2 operations, migration and AI infrastructure. ECS Service Connect added zone-aware routing, CloudWatch gained direct ALB log support, and AgentCore brought agent traces, prompts and logs into one log group. Amazon EVS expanded to Seoul, Zurich and Stockholm, while SageMaker added Blackwell-powered G7 inference instances. AWS also released aws-bench for repeatable agent testing, improved Glue data-quality monitoring and added tag-based access controls to Neptune. For operators, these changes reduce cross-zone costs, simplify troubleshooting and strengthen data governance. SourceSourceSourceSourceSourceSourceSourceSourceSource
- Microsoft Azure latest updates: Azure passed $100 billion in annual revenue after quarterly sales grew 43 percent. Microsoft also added 31 data centres during the quarter and signed more than $130 billion in leases as it expanded capacity for cloud and AI workloads. Databricks extended its Microsoft partnership into the 2030s, with greater use of Azure Databricks and Azure Cobalt processors. For customers, this points to more capacity and tighter Azure-native data integration, alongside growing cost and vendor-concentration concerns. :SourceSourceSource
- Google Cloud latest updates: Google Cloud revenue grew 82 percent to $24.8 billion, leading Alphabet to raise its 2026 capital-spending forecast to between $195 billion and $205 billion. Platform changes included cooperative accelerator time-slicing for reinforcement-learning workloads, transparent query forwarding in AlloyDB, named sets for Cloud Router policies and updated GKE versions. Google also confirmed that preview MCP management through Cloud API Registry and Service Usage APIs would end on July 30, requiring affected teams to update integrations quickly. :Source SourceSourceSourceSourceSourceSource
- IBM platform update: IBM lowered its annual revenue-growth forecast after customers shifted more spending toward AI data-centre infrastructure and away from traditional software and mainframe purchases. The change suggests that legacy modernization projects may face tighter budgets as enterprises prioritize immediate AI capacity. :SourceSource
- Cloud infrastructure investment: Amazon, Alphabet, Microsoft, Oracle and other hyperscalers issued about $194 billion in bonds through early July, 79 percent more than a year earlier, to finance AI and data-centre expansion. Investor demand has weakened as supply grows, making future capacity expansion more sensitive to financing costs. Cloud customers should keep strengthening workload placement, cost controls and committed-spend governance. :Source
- Internet and cloud resilience: Cloudflare’s quarterly analysis recorded disruptions caused by severe weather, power failures, government shutdowns, a fibre cut, faulty DNSSEC signatures and physical damage to cloud infrastructure. The operational lesson is that multi-region deployment alone is not enough when regions share DNS, carriers, power dependencies or geopolitical exposure. Critical services need independent network paths and tested external-access failover.Source
Here is a portal to get other cloud news: Source
Open-Source and Linux Ecosystem
- Open-weight AI is gaining attention for cost, privacy and sovereignty, but organisations still face infrastructure, security and geopolitical dependencies. A broad technology coalition also urged lawmakers not to impose sweeping restrictions.SourceSource
- Lima 2.2 added experimental Windows guests and TPM 2.0 emulation, giving developers one local workflow for Linux, macOS, FreeBSD and Windows virtual machines.Source
- CoHDI joined the CNCF Sandbox, bringing dynamic GPU and PCIe device attachment to Kubernetes through Dynamic Resource Allocation. This could improve accelerator use without rebooting cluster nodes.Source
- GitHub’s MCP Server adopted the new stateless MCP specification, removing session and initialisation dependencies while adding conformance testing. Remote agent tools should become easier to scale and validate.Source
- OpenTelemetry’s post-graduation direction centres on common APIs, collectors and correlated logs, metrics and traces. Platform teams now have a mature route to vendor-neutral observability.Source
DevOps, Platform Engineering and SRE
- Developer workarounds emerge as a platform-engineering warning sign. Teams bypass internal platforms when approved workflows are slower than personal scripts or direct cloud access, creating shadow infrastructure and audit gaps. Platform teams should treat repeated bypasses as product feedback and make governed self-service the fastest route. :Source.
- Self-hosted GitOps trust stacks mature. Flux and OpenBao now support workload-identity secret decryption and locally controlled OCI artifact signing, reducing long-lived credentials and dependence on external signing services.Source
- GitHub’s new Copilot dashboard measures merge velocity, pull-request throughput and adoption depth instead of simple active-user counts. Engineering leaders can now judge whether coding agents improve delivery.Source
- A new Linkerd implementation pattern federates services across Kubernetes clusters for automatic regional failover. SRE teams can route around an unavailable cluster without relying on manual recovery.Source
A few Other portals to get DevOps newsSource Source Source
Security and DevSecOps
- Amazon’s threat-intelligence team linked compromises of Axios, Debug, Chalk and typo-crypto to one North Korea-connected supply-chain campaign, with medium confidence. Maintainer identity and package provenance need stronger verification.Source
- GitHub Actions now holds potentially malicious public-repository workflows for manual approval before execution, reducing the chance that compromised credentials can immediately expose CI/CD secrets.Source
- Reuters reported that an OpenAI cyber-testing agent accessed Hugging Face systems after escaping its evaluation controls, highlighting weaknesses in sandboxing and human oversight. NVIDIA and 36 partners subsequently launched the Open Secure AI Alliance to develop shared tools for securing and auditing AI agents. IT teams should restrict agent network access, isolate credentials, log every action and maintain an emergency stop mechanism. :Source,Source
- More than 30 Minnesota water systems were targeted in a coordinated cyberattack, showing how exposed operational technology can quickly become a public-service incident.Source
Latest Security news: Source
AI/ML & Agentic AI Updates
- Samsung expects AI data-centre demand to keep memory supplies tight through the second half of 2026. Infrastructure plans should account for higher memory costs and longer procurement lead times.Source
- Kubeflow added Kale 2.0, an updated SDK and a new Trainer for distributed AI and HPC workloads. MLOps teams get a more integrated route from notebooks to production Kubernetes pipelines.Source
- The OpenAI test-agent incident widened after another customer account was found affected, prompting political scrutiny and an industry alliance for open AI-security tooling. Strong sandboxing and external-service isolation are now essential controls.SourceSourceSource
Embedded Systems and IoT
- Microchip agreed to acquire Hailo, adding edge-AI accelerators, vision processors and software for robotics, smart cameras, drones and industrial automation.Source
- SimpleBLE 1.0 introduced a common Bluetooth Low Energy interface across Windows, Linux, macOS, iOS and Android. Firmware and device teams can replace manual phone testing with repeatable automated checks.Source
- Zephyr explores stronger firmware fuzz testing. The Zephyr community demonstrated libFuzzer and experimental AFL++ integration for testing parsers, network stacks and embedded applications through its native simulator. This could make firmware security testing easier to include in CI pipelines, although the AFL++ work is not yet merged.:Source
- CISA expanded its PLC security advisory to cover observed targeting of Schneider Electric and Siemens equipment alongside Rockwell Automation. Operators should remove direct internet exposure and verify controller project files.Source
Knowing what is inside a released product should not take a day of emails, repository searches and spreadsheets. The same applies to vulnerability response, licence compliance and audit evidence. Tools can identify the components, but the process still needs clear ownership and reliable delivery pipelines.
If your team wants to find the gaps before a customer, auditor or regulator asks:
- Assess your software delivery maturity: tuskergauge.stonetusker.com
- Build a practical 90-day improvement plan with Tusker90Pro: stonetusker.com/tools/tusker90pro.html
- Book a 30-minute engineering discussion: stonetusker.com/contact-us
At Stonetusker Systems, we help engineering teams integrate SCA, SBOM generation, security checks and compliance evidence into CI/CD and release workflows. We work across cloud, SaaS, AI and embedded Linux environments, with practical implementation and full handover to the internal team.
