AI code generation is running out of control, with eight-in-ten organizations adopting AI tools faster than they can develop policies to govern them, new research has warned.

According to GitLab's AI Accountability Report, 92% are facing governance challenges with AI-generated code as rapid adoption continues.

More than nine-in-ten have two or more AI coding tools in active use, the study found, while 54% have three or more. Meanwhile, 78% report that developers are writing and committing code faster since adopting AI tools.

Teams are generally happy with the results, with six-in-ten saying that the ROI of AI coding is better than they'd expected. More than three quarters (78%) also report faster code output and 73% said overall code quality has improved.

However, while 79% agree that individual developer productivity has improved with AI, the overall software delivery process has not accelerated at the same pace.

Indeed, 82% say that AI-generated code risks creating a new form of technical debt that organizations aren't prepared to manage.

"AI coding tools have delivered on their promise of speed," said Manav Khurana, chief product and marketing officer at GitLab.

"But the events of the past few months, including supply chain attacks, reliability issues, and regulators tightening expectations around AI traceability and provenance are making clear that speed without control is a liability, not an advantage."

AI coding is creating new bottlenecks

Notably, 85% agree that AI has shifted the bottleneck from writing code to reviewing and validating it, and 84% that the biggest challenge with AI-generated code is governing what happens to it after it's created.

Nearly-three quarters are concerned about the maintainability of AI-generated code in their organization's codebase.

GitLab also raised concerns about a prevailing trend of overconfidence when it comes to AI coding. The majority (87%) said they’re confident that teams could determine within 24 hours whether AI-generated code contributed to a production incident, for example.

Yet more than one-third (34%) of organisations fail to spot potential issues before an incident took place.

This appears to be down to difficulty distinguishing AI-generated from human-written code (43%), fragmented toolchains (40%), and systems that don't track code origin (39%).

Only 28% say their software development lifecycle (SDLC) tools are fully integrated with shared data and workflows.

New governance practices are needed

According to GitLab, what’s missing is clarity around governance. The majority (83%) of organizations identify AI-generated code accumulation as a risk to manage now, with 44% calling it a top technology risk.

On the upside, 91% of survey respondents said they are likely to invest in AI code governance tools in the next 12 months, and 98% have already allocated or expect to allocate budget toward these efforts.

Crucially, 85% agree the next phase of AI in software will focus less on generating code and more on governing it.

"The teams thinking ahead are already asking the harder question: can we actually control all the code we’re generating?" said Khurana.

"The organizations that will ship trusted software faster are the ones building the foundations of accountability with context, traceability, and governance baked into the platform, not just bolted on after the fact."

AI governance has been a persistent challenge for developers, with research from Aikido last year concluding that AI-generated code is now the cause of one-in-five breaches.

The study noted that 69% of security leaders, engineers, and developers had identified serious vulnerabilities in AI-generated code.

FOLLOW US ON SOCIAL MEDIA

The UK government has launched a new scheme to boost adoption of the Software Security Code of Practice by appointing a series of industry champions.

Under the plans, a cohort of ‘Software Security Ambassadors’ will promote the code of practice across various different sectors, showcasing examples of practical implementation and giving feedback to inform future policy improvements.

The first batch of participating organizations includes the Department for Science, Innovation, and Technology (DSIT) itself, along with the National Cyber Security Centre (NCSC).

Accenture, Cisco, ISACA, Lloyds Banking Group, Sage, Palo Alto Networks, and others have also backed the scheme.

"By acting as ambassadors, signatories are committing to a process of transparency, development and continuous improvement. The implementation of this code of practice will take time and, in doing so, may bring to light issues that need to be addressed," DSIT said in a statement confirming the announcement.

"Signatories and policymakers will learn from these issues as well as the successes and challenges for each organization and, where appropriate, will share information to help develop and strengthen this government policy."

What is the Software Security Code of Practice?

The Software Security Code of Practice was unveiled by the NCSC in May last year, setting out a series of voluntary principles defining what good software security looks like across the entire software lifecycle.

Aimed at technology providers and organizations that develop, sell, or procure software, the code offers best practices for secure design and development, build-environment security, and secure deployment and maintenance.

The code also emphasizes the importance of transparent communication with customers on potential security risks and vulnerabilities.

Developed with the NCSC, the code is designed to reflect internationally recognized best practices, such as the US Secure Software Development Framework (SSDF) and the EU’s Cyber Resilience Act (CRA).

Software security in the spotlight

The launch of the code came in direct response to growing concerns surrounding software security on both sides of the Atlantic. In the US, for example, the Secure by Design Pledge was launched by CISA in 2023.

This voluntary scheme asks software developers and providers to place a stronger emphasis on product security.

According to figures from the DSIT, more than half (59%) of organizations experienced software supply chain attacks in the past year, underlining the growing risks faced by UK enterprises and consumers alike.

In a separate survey from ISC2, more than half of respondents identified software vulnerabilities in supplier products as the most disruptive cybersecurity threat to their organisation’s supply chain.

ISC2 said it plans to help drive adoption of the code by promoting awareness through educational and thought leadership content, and referencing it in relation to certifications, training, and guidance that support secure software development.

It will also work with organizations across the software supply chain to encourage practical implementation and require its own partners to incorporate it.

“Promoting secure software practices that strengthen the resilience of systems underpinning the economy, public services and national infrastructure is central to ISC2’s mission,” said Tara Wisniewski. ISC2 EVP for advocacy and strategic engagement.

“The code moves software security beyond narrow compliance and elevates it to a board-level resilience priority. As supply chain attacks continue to grow in scale and impact, a shared baseline is essential and through our global community and expertise, ISC2 is committed to helping professionals build the skills needed to put secure-by-design principles into practice.”

FOLLOW US ON SOCIAL MEDIA

A majority of developers are using AI to create code, but even though most don't trust the output, they're failing to take steps to verify it.

That's according to a survey from code review company Sonar, which found that 72% of developers use AI tools every day, with the technology helping to write up to 42% of committed code.

Notably, 96% of developers surveyed said they don't fully trust that AI-generated code is functionally correct – but fewer than half say they review it before committing.

Sonar said this leads to "verification debt", a term used by AWS CTO Werner Vogels while discussing the use of AI in software development at the company's annual re:Invent conference in December.

Tariq Shaukat, CEO of Sonar, said the research highlights a “fundamental shift” in software development, whereby value is no longer simply defined by the speed at which code can be written, but by the "confidence in deploying it”.

"While AI has made code generation nearly effortless, it has created a critical trust gap between output and deployment,” he said. "To realize the full potential of AI, we must close this gap."

Why devs are slacking on AI-generated code

There may be a good reason for the failure to check AI-generated code, the study noted, mainly as it typically takes more time than reviewing human-written code.

"While AI is supposed to save time, developers are spending a significant portion of that saved time on review," the Sonar report said, adding: "In fact, 38% of developers say reviewing AI-generated code requires more effort than reviewing code written by their human colleagues."

One reason for that is AI often produces code that looks correct but isn't reliable, a statement that 61% of respondents agreed with.

"That's a critical finding — it means AI code can introduce subtle bugs that are harder to spot than typical human errors," the report noted. "The same percentage (61%) agree that it 'requires a lot of effort to get good code from AI' through prompting and fixing."

How developers are using AI

The survey found the most common use for AI by developers was for proofs of concept and prototypes (88%), followed by the creation of production software for internal, non-critical workflows (83%), customer-facing applications (73%), and business-critical internal software (58%).

Those surveyed said AI was most effective at writing documentation, explaining existing code, and vibe coding. Just 55% of those polled said such tools were effective for assisting development of new code, but that task had the highest adoption rate at 90%.

"Developers have embraced AI as a daily partner, but they're finding it's a much better 'explainer' and 'prototyper' than it is a 'maintainer' or 'refactorer' — at least for now," the report states.

"It's highly effective at generating new things (docs, tests, new projects) but struggles more with the complex, nuanced work of modifying and optimizing existing, mission-critical code."

Too much trust in AI tools

The Sonar report is the latest in a string of studies highlighting the benefits of AI for developers, but a prevailing lack of trust among many on their outputs.

Best practices have also been slipped among many since the influx of these tools in the profession, research shows. In a survey from Cloudsmith last year, for example, nearly half of developers (42%) said their codebases are now largely AI-generated.

Respondents specifically highlighted productivity and efficiency gains while using the technology, yet only 67% said they actively review code before deployments.

Cloudsmith warned this lax approach to code testing and reviews could have dire consequences for enterprises, leaving them open to an array of security risks and vulnerabilities.

FOLLOW US ON SOCIAL MEDIA

Nearly three-quarters of organizations have suffered at least one security breach or incident in the last year that can be blamed on insecure coding practices.

Analysis from SecureFlag found 74% of organizations have suffered an incident as a result of dodgy code, with nearly half of those hit by multiple breaches.

The report comes as AI is beginning to take over some coding duties from developers. Debate remains over whether that code is secure. Some say AI can code better than human developers, but research has suggested insecure code could be easily replicated by AI.

Andrea Scaduto, CEO and co-founder of SecureFlag, said the study highlights the risks faced by enterprises rushing to automate aspects of software development.

"This should be a wake-up call for every business that develops software,” she said. “It’s frankly shocking that in 2025 so many breaches are still happening because of avoidable coding flaws.”

It wasn't all bad news, however. The report revealed that companies are ramping up developer security training as a result of lingering issues. Nearly half (44%) said they offer training updates on a quarterly basis, while 29% offer fresh training schemes monthly.

The report said this shows enterprises are conscious of the risks associated with insecure code and are taking proactive steps to mitigate risks. Indeed, nine-in-ten said they were formally assessing their development teams' secure coding skills.

The most common training format is video-based tutorials (46%) followed by eLearning platforms (42%). Classes, both in-person and virtual, were also popular for four-in-ten companies, as were interactive labs and hands-on environments.

A third of companies surveyed said they run hacking games such as "capture the flag".

ROI for developer security training

Challenges remain, however. According to SecureFlag, respondents said measuring return on investment (ROI) remained a hurdle (40%), followed by a lack of useful content, not enough time, low engagement from employees, and insufficient budget — as well as lack of leadership support.

"Even though most executives believe in the value of training, they struggle to prove in concrete terms how these programs reduce risk or justify their cost, a clear sign that quantifying the impact of secure coding initiatives remains elusive," the report noted.

"Overall, the data highlights that proving ROI to stakeholders and allocating sufficient time and content resources are the prevailing hurdles to overcome, even more so than money or buy-in."

Though they may lack the hard data to prove a ROI, nine-in-ten of those surveyed believe that secure coding has reduced the number of security bugs in development, and view training as a solid move to prevent such incidents.

"Breaches stemming from coding mistakes are preventable – but only if companies invest in proper training," said Emilio Pinna, SecureFlag’s CTO and co-founder. "It’s far cheaper to train a developer than to clean up after a breach."

MORE FROM ITPRO

• Want developers to build secure software? You need to ditch these two programming languages
• The NCSC wants developers to get serious on software security
• Shifting left might improve software security, but developers are becoming overwhelmed

Software developers are using AI at record levels, new research shows, but they're hesitant to place too much faith in the technology.

Findings from Stack Overflow’s annual Developer Survey show the use of technology in the software industry has surged over the last 12 months, spurred on by the emergence of AI coding tools and, most recently, agentic AI solutions.

The survey found 84% of developers currently use - or plan to use - AI tools in their daily workflows. This marks a third consecutive yearly increase and a jump from 76% in last year’s edition.

OpenAI’s GPT model range was cited as the most frequently used by developers alongside Anthropic’s Claude Sonnet range and Google’s Gemini Flash models.

Yet despite the increasing uptake of AI tools in the profession, a growing number of developers aren’t willing to put their trust in the technology. Nearly half (46%) said they “don’t trust the accuracy” of the output from AI, which marks a significant increase compared to 31% in the 2024 survey.

Notably, even if AI improves to the extent that it can carry out tasks on behalf of developers, many said they would still prefer to ask a colleague for assistance.

Three-quarters (75.3%) said they simply don’t trust AI answers and would refer to a co-worker while 61.7% revealed they frequently have ethical or security-related concerns about AI-generated code.

Crucially, 61.3% said they’d refer to a colleague for assistance because they want to fully understand their code.

Prashanth Chandrasekar, CEO of Stack Overflow, said the findings show that while the benefits of AI are becoming clearer, lingering concerns about security and safety still remain.

“The growing lack of trust in AI tools stood out to us as the key data point in this year's survey, especially given the increased pace of growth and adoption of these AI tools,” Chandrasekar said.

“AI is a powerful tool, but it has significant risks of misinformation or can lack complexity or relevance.”

Chandrasekar added that pursuing an approach that “leans heavily on trustworthy, responsible use of data from curated knowledge bases” is now critical.

Similarly, ensuring humans are kept in the loop is an equally important consideration for development teams.

“By providing a trusted human intelligence layer in the age of AI, we believe the tech enthusiasts of today can play a larger role in adding value to build the AI technologies and products of tomorrow.”

Developers are bogged down in buggy code

While trust in AI tools was a key issue highlighted by developers, growing frustration over poor quality output was also raised.

Nearly half (45%) of respondents said they’re bogged down in time-consuming debugging as a result of AI-generated code. The survey findings align with previous research highlighting concerns over AI code generation.

In a study from Cloudsmith, nearly half of developers using AI said their codebases are now largely AI-generated. While devs said the technology has enabled them to improve productivity and efficiency, the study warned that a concerning number of teams are overlooking crucial security considerations.

Around a third of developers don’t review AI-generated code before deployments, Cloudsmith found.

Agentic AI hasn’t hit the mainstream yet

Agentic AI has emerged as the latest trend in the AI space this year, yet while it’s taken the industry by storm, uptake of agentic solutions hasn’t yet taken off in the development community, according to Stack Overflow.

Only 31% of developers said they used AI agents in their daily workflows, while just 17% plan to use them. More than one-third (38%) said they don’t plan to use AI agents at all in the near future.

Notably, among those that have used AI agents, around 69% agreed they experienced a marked increase in productivity and efficiency.

A host of major industry players have jumped on the agentic AI bandwagon in recent months, with Salesforce in particular dialing in on the technology. Earlier this year, CEO Marc Benioff suggested the company might not hire any new software engineers as a result of its own internal successes with the technology.

With the emergence of this latest iteration of the technology, some industry stakeholders have suggested AI might negatively impact the workforce, particularly entry-level roles.

Stack Overflow’s survey shows developers aren’t concerned about the prospect of AI-related job cuts, however. Nearly two-thirds (64%) of respondents said they don’t perceive AI as a threat to their jobs, marking a decrease compared to the 2024 survey.

MORE FROM ITPRO

• AI coding tools are booming – and developers in this one country are by far the most frequent users
• Want developers to build secure software? You need to ditch these two programming languages
• AI tools aren’t helping developers save time on software testing

Hundreds of Model Context Protocol (MCP) servers around the world are open to abuse, with vulnerabilities that put vibe coders and their organization's sensitive assets at risk.

Introduced late last year, MCP servers are an easy-to-use extension of LLMs, thanks to the simplicity of their protocols, and have come into widespread use due to the broad availability of independently developed MCPs.

However, according to analysis from Backslash Security, around half of the 15,000-plus MCP servers in existence are dangerously misconfigured or carelessly built. The resulting vulnerabilities are in some cases catastrophic, the company warned.

They fall under two general headings. First is the MCP ‘NeighborJack’ vulnerability, whereby hundreds of MCP servers are explicitly bound to all network interfaces (0.0.0.0), making them accessible to anyone on the same local network.

This was the most common vulnerability found, with hundreds of cases discovered.

"Imagine you’re coding in a shared co-working space or café. Your MCP server is silently running on your machine," the researchers said.

"The person sitting near you, sipping their latte, can now access your MCP server, impersonate tools, and potentially run operations on your behalf."

Meanwhile, dozens of MCP servers allowed arbitrary command execution on the host machine thanks to careless use of a subprocess, a lack of input sanitization, or security bugs such as path traversal.

Most concerning of all, on several MCP servers both vulnerabilities were present, allowing bad actors to take full control of the host machine running the server.

Malicious actors that come across these MCP servers would have full access to run any command, scrape memory, or impersonate tools used by AI agents, Backslash said.

Meanwhile, beyond code execution, MCPs can serve as stealthy pathways for prompt injection and context poisoning, Backslash warned. Malicious or manipulated public content can change what an LLM sees - returning misleading data, or rerouting agent logic.

“Our research highlights several prevalent MCP server weaknesses that can open enterprise environments to threat vectors including remote code execution, data exposure, and network traversal,” said Yossi Pik, co-founder and CTO of Backslash Security.

More trouble on the way for MCP servers

In a yet-to-be-released finding, Backslash said it also identified an exploit path involving a seemingly benign public document that can trigger a cascading compromise, because the MCP silently connected it into the LLM agent’s logic without proper boundaries.

The issue here wasn’t a vulnerability in the MCP code itself, but rather in the configuration of the data source it accessed. Backslash said the issue affects a 'very popular' tool with tens of thousands of users and that it's currently working with the vendor to coordinate responsible disclosure.

The company has now launched a free self-assessment tool for vibe coding environments to help security teams gain visibility into the vibe coding tools being used in their organizations, continuously gauging the risk posed by large language models (LLMs), MCP servers, and IDE AI rules in use.

"It's critical to give developers and vibe coders the tools and guidance to safely navigate this emerging attack service, which is why we’ve created the MCP Server Security Hub," said Pik.

"Developers will continue to tap MCP servers' flexibility and utility, so we wanted to give the community a safer means of doing so."

MORE FROM ITPRO

• The NCSC wants developers to get serious on software security
• Shifting left might improve software security, but developers are becoming overwhelmed
• Software security debt is spiraling out of control

Nearly half of developers using AI to support operations say their codebases are now largely AI-generated, new research shows.

A survey from Cloudsmith found 42% of developers admitted to having AI-filled codebases, with respondents noting that the use of AI has helped them markedly improve productivity and efficiency.

Yet despite the influx of AI-generated code, long-standing best practices are being overlooked, the study warned. Just over two-thirds (67%) of developers said they review code before deployments, raising concerns over software security.

Glenn Weinstein, CEO at Cloudsmith, said the use of AI in software development does present opportunities for development teams, but warned against placing complete faith in AI.

“Software development teams are shipping faster, with more AI-generated code and AI agent-led updates,” he said.

“AI tools have had a huge impact on developer productivity, which is great. That said, with potentially less human scrutiny on generated code, it’s more important that leaders ensure the right automated controls are in place for the software supply chain.”

The study noted that a growing number of developers are not only becoming reliant on AI-generated code, but are also placing a greater degree of trust in code written by AI tools.

Around 20% said they trust AI-generated code “completely”, the study found.

Notably, there are those in the profession taking a more considered approach to the use of AI in code generation. More than half (59%) said they apply additional scrutiny to AI-generated packages, for example, but a gap on enforcement is emerging at some enterprises.

Around 17% said they have no control policies in place over the use of AI in development processes, or for the use of AI-generated code. Similarly, roughly one-third (34%) noted they use tools that enforce policies specific to AI-generated packages, but this still leaves a glaring gap and could leave them open to threats.

The rise of generative AI and its use in software development has been mirrored by a significant rise in “AI-specific exploits”, Cloudsmith noted. Among those highlighted in the study were ‘slopsquatting’, whereby attackers weaponize hallucinated package names suggested by coding assistants.

Developers and security practitioners alike also voiced concerns over their ability to spot potential exploits of flaws, with just 29% stating they feel “very confident” in their ability to detect vulnerabilities.

This is particularly risky when working with open source libraries, the study warned, where AI tools are likely to draw suggestions.

AI-generated code is in vogue

The use of AI-generated code has become a big talking point in the tech industry over the last year, with some leading companies having turned to the trend to speed up development.

In November last year, Google CEO Sundar Pichai revealed that around a quarter of the tech giant’s internal source code was AI-generated, and that’s likely increased since then.

Speaking during an earnings call at the time, Pichai said Google was using AI across development teams both to speed up coding processes and to reduce manual toil for developers.

Notably, Pichai insisted that all AI-generated code was subject to robust safety checks by human workers. Engineers are often kept in the loop to review this code, he noted.

Microsoft has also jumped on the bandwagon in this regard. During an appearance at Meta’s LlamaCon conference in April, CEO Satya Nadella told Mark Zuckerberg up to 30% of its code was written with AI.

“I’d say maybe 20%, 30% of the code that is inside of our repos today and some of our projects are probably all written by software,” Nadella told Zuckerberg.

Nadella expects the volume of AI-generated code at the company to also steadily increase in the coming years.

MORE FROM ITPRO

• Half of developers want to quit over "embarrassing" tech stack
• Shifting left might improve software security, but developers are becoming overwhelmed
• AI coding tools are finally delivering results for enterprises

Nearly half of enterprises are trying to "shift left" in a bid to shore up software security, but developers are reporting significant issues with the strategy.

False positives, the faster pace of development thanks to AI, and challenges integrating tools are hampering progress.

That's according to research by AI security firm Pynt that focused on the adoption of shift left practices — referring to a strategy of spotting flaws and security issues earlier in the software development cycle when they're easier to fix.

The survey of 250 security professionals found 47% of organizations had implemented a shift left approach to software development, with a further 27% working to do so.

But a quarter of developers felt overwhelmed by the volume of vulnerabilities, and more than a third saw false positives as the main challenge to implementing a successful shift-left strategy, followed by integration issues and vulnerability overload.

The study raises serious questions over whether this approach to software development is actually reducing overall risks, or merely increasing complexity, according to Pynt chief executive Tzvika Shneider.

"Everyone talks about shifting left, but few are seeing the security gains they expected," said Shneider. "Most organizations have tools in place, but they still struggle with noise, process friction, and developer resistance."

"AI accelerates how software is developed and shipped, forcing security to keep pace, Shneider added.

The research also found that the vast majority of companies that had shifted left had turned to software tools to help the process, but 31% said that integrating those tools within development workflows continued to be a major barrier.

The most popular tools are Static Application Security Testing (SAST), Software Composition Analysis (SCA) and Dynamic Application Security Testing (DAST), with each used by about a third of respondents.

Software security priorities are causing friction

Two-thirds of respondents said they prefer to fix bugs in app code rather than with rules in post-production, highlighting friction between developers and security teams. The former prioritize feature development and see security as a burden, while the latter wants to see flaws fixed rapidly.

"Shift right is easier since it doesn’t require extensive coordination between multiple teams, whereas Shift Left demands a collaborative effort across development, security, and testing teams,” the report noted.

"Shift Left was meant to improve security, but many organizations are finding that execution challenges are holding them back," added Shneider. "Security leaders must rethink their approach to reduce friction between security and development teams while maintaining effective risk management."

Pynt said that automation in security testing could help, and called for improved collaboration between security and development teams, including integrating security into testing phases.

Europeans are ahead adopting shift left practices, the survey found, with Germany and the UK both at 52%. Developer teams in the US, however, aren't quite up to scratch in this regard, researchers found, with just 42% of enterprises having adopted the approach.

The report follows earlier research that suggests enterprise security teams are struggling to keep up with the adoption of AI tools. Similar research found showing the rise in AI coding tools may actually be slowing down development thanks to the security headaches it causes.

MORE FROM ITPRO

• Anthropic’s new AI model could be a game changer for developers
• 30% of Microsoft's code is now AI-generated, and that's bad news for devs
• Java might’ve just turned 30, but it’s still going strong and here to stay

The NCSC’s new Software Security Code of Practice is a “clear call to developers” to beef up secure by design practices, according to a senior cybersecurity expert.

James Neilson, SVP International at OPSWAT, said the new rules introduced by the security agency will play a key role in encouraging organizations to build more secure software solutions.

“This new code is a welcome move,” he said. “It isn’t just a checklist — it’s a call to get serious about end-to-end security. A software supply chain is only as strong as its weakest link.”

The new code of practice has been introduced following a review conducted by the agency last year. At the time, the NCSC said technology markets “do not incentivize organizations to develop software that is ‘secure by default’.”

“Understandably, organizations will prioritize growth and profit rather than the security and resilience of their products and services,” the NCSC said in a blog post unveiling the code.

“When the importance of cybersecurity is recognized, we know from research that software developers are not necessarily security experts, and may find it hard to efficiently build software that is secure using tools that are often inaccessible and complicated.”

While the new code of practice is voluntary, the NCSC nonetheless believes it will provide a clear “market baseline” for software security. What this means is that software developers and suppliers are now expected to adhere to a minimum set of standards to ensure products are resilient to growing security threats.

What the Software Security Code of Practice covers

The new code of practice contains 14 core principles, split across four themes, according to the NCSC. Organizations adhering to the code will be required to appoint a ‘Senior Responsible Owner’, who will hold a senior leadership role, to ensure these principles are met.

The four key themes outlined in the code include:

• Secure design and development
• Build environment security
• Secure deployment and maintenance
• Communication with customers

A particular focus has been placed on the ‘secure design and development’ theme, which applies predominantly to software vendors and encourages them to follow an established secure development framework.

The Senior Responsible Owner will also be required to assess the risks associated with software developed at their respective organization, as well as any risks linked to the ingestion and maintenance of third-party components throughout the development lifecycle”.

Elsewhere, the ‘secure deployment and maintenance’ theme seeks to bolster software and application security “throughout its lifetime”.

This requires vendors to distribute software to customers that is secure at the point of sale and to publish an “effective vulnerability disclosure process” to ensure customers are made aware of any security risks.

All told, the agency believes these rules will have a positive downstream effect, improving supply chain security and preventing costly remediation processes for developers.

“The Code provides a framework to help organizations measure their progress, identify improvements, and provide tangible evidence of their commitment to security,” the NCSC said in its blog post.

“It includes practical guidance to make clear to vendors what is required to ‘bake’ cybersecurity into all stages of the development life cycle. Doing this addresses cybersecurity problems at the root cause and prevents costly redesigns later on.”

What about open source software?

Notably, the NCSC said open source developers and maintainers are “not considered the primary audience” with respect to the new code of practice.

“This Code of Practice is most relevant to the sale and distribution of proprietary software as the Code aims to set out the responsibilities of software vendors in the context of business-to-business commercial relationships,” the agency said.

The NCSC added that open source developers and maintainers bear “no formal commitment” with regard to the security of their supply chain or the maintenance of their code.

In other words, responsibility for managing any risks associated with open source code rests on the end-user or proprietary developer using this in their software.

Regardless, Neilson noted that the new code of practice will prompt organizations to consider the potential risks here, which again will ultimately bolster broader supply chain security.

“Software developers often use third-party components, including open source software, to speed up development and add features,” he said. “However, these may contain known or newly discovered vulnerabilities, or even ones introduced maliciously.”

“By securing their software supply chains — scanning for hidden threats, validating SBOMs, securing build environments, and ensuring that what is delivered is exactly what was intended — vendors can build greater resilience and trust into their software.”

MORE FROM ITPRO

• Software security debt is spiraling out of control
• US lawmakers are pushing for a shift to memory safe programming languages, but will it improve software security?
• NCSC CTO says what everyone is thinking about software security

Only a third of organizations employ adequate testing practices in AI application development, according to new research, prompting calls for increased red teaming to reduce risks.

Analysis from Applause found 70% of developers are currently developing AI applications and features, with over half (55%) highlighting chatbots and customer support tools as their primary focus at present.

Yet despite an acceleration in AI application development, a concerning number of organizations are overlooking quality assurance (QA) efforts during the software development lifecycle.

The study warned this trend is having an adverse impact on both quality and long-term return on investment (ROI).

“The results of our annual AI survey underscore the need to raise the bar on how we test and roll out new generative AI models and applications,” said Chris Sheehan, EVP of high tech & AI at Applause.

AI application development needs a human touch

A key talking point of the Applause study centered around human involvement in the development lifecycle. With developers ramping up the use of generative AI tools in their daily workflows, the need for a ‘human touch’ has become critical to identify and remediate a range of issues.

These include issues such as inaccuracy, bias, and toxicity, the study noted.

Researchers found the top QA-related activities that involve human testing include prompt and response grading (61%), accessibility testing (54%), and UX testing (57%).

Applause added that humans are also crucial in training industry-specific or ‘niche’ models, particularly with the rise of agentic AI applications that interact directly with end-users.

Notably, the study found that only one-third (33%) of organizations currently employ red team testing in application development processes. Red teaming refers to adversarial testing practices - commonly used in cybersecurity - to identify potential weak points in platforms or applications.

Researchers called for a heightened focus on red teaming in AI application development, noting that this could play a key role in highlighting the aforementioned issues such as model bias or inaccuracy.

Application flaws persist

The study from Applause found that customer-related issues are becoming a frequent problem for enterprises. Nearly two-thirds of customers using generative Ai in 2025 reported encountering some sort of issue.

Over a third (35%) encountered biased responses, hallucinations (32%), and offensive responses (17%).

Hallucinations have been a persistent problem in AI development for some time now.

While the situation has improved markedly since the early days of the generative AI boom, the issue is still causing a degree of uncertainty among enterprise IT leaders.

In a study by KPMG in August 2024, six-in-ten tech leaders specifically highlighted hallucinations as a key concern with adopting or building generative AI tools and applications.

Sheehan noted that positive changes are being made by development teams, however. Many enterprises surveyed by the firm are “already ahead of the curve” and are integrating AI testing measures into the development lifecycle at an earlier stage.

This includes more robust model training methods which employ “diverse, high quality” datasets. Some enterprises are also warming to red teaming practices, he added.

“While every generative AI use case requires a custom approach to quality, human intelligence can be applied to many parts of the development process including model data, model evaluation and comprehensive testing in the real world.

“As AI seeps into every part of our existence, we need to ensure these solutions provide the exceptional experiences users demand while mitigating the risks that are inherent to the technology.”

MORE FROM ITPRO

• Developers spend 17 hours a week on security — but don't consider it a top priority
• Java developers are facing serious productivity issues
• Want developers to build secure software? You need to ditch these two programming languages

AI might not replace software engineers just yet as new research from OpenAI reveals ongoing weaknesses in the technology.

Having created a benchmark dubbed ‘SWE-Lancer’ to evaluate AI’s effectiveness at completing software engineering and managerial tasks, researchers concluded that the technology is lacking.

“We evaluate model performance and find that frontier models are still unable to solve the majority of tasks,” researchers said.

Researchers found that, while AI excels in certain areas, it is limited in others. For example, AI agents are skilled at localizing problems but bad at working out what the root cause is.

While they can pinpoint the location of an issue with speed and use search capabilities to access necessary repositories faster than humans can, their understanding is limited in terms of how an issue spans across different components and files.

This frequently leads to solutions that are incorrect or insufficiently comprehensive, and agents can often fail by not finding the right file or location to edit.

In a comparison between two OpenAI models, o1 and GPT-4o, and Claude’s 3.5 Sonnet model, researchers found they all failed to entirely solve one particular user interface (UI) problem.

While o1 solved the basic issue, it missed a range of others, and GPT-4o failed to solve even the initial problem. Sonnet was quick to identify the root cause of the issue and fix the bug, but the solution was not comprehensive and did not pass the researcher’s end-to-end tests.

All told, researchers said that while AI coding tools have the capacity to make software engineering more productive, but that users need to be wary of the potential flaws in AI-generated code.

Are AI coding tools more trouble than they’re worth?

While businesses are ramping up the use of AI coding tools, there have been plenty of warning signs to make firms stop and consider whether the tools are worth it.

Research from Harness earlier this year found that many developers are becoming increasingly bogged down with manual tasks and code remediation due to the increased use of AI coding tools.

The study noted that while these tools may offer huge benefits to software engineers, experts say they are still littered with weaknesses and lack some of the capabilities of human engineers.

“While these tools can boost efficiency, in their current state they often result in a surge of errors, security vulnerabilities, and downstream manual work that burdens developers," Sheila Flavell, COO of FDM Group, told ITPro.

The risk of vulnerabilities and malicious code being introduced into organizations is also significantly higher when AI coding tools are used, according to Shobhit Gautam, security solutions architect at HackerOne.

“AI-generated code is not guaranteed to follow security guidelines and best practices as defined by the organization standards. As the code is generated from LLMs, there is a possibility that third-party components may be used in the code and go unnoticed,” Gautam told ITPro.

“Aside from the risk of copyright infringement, the code hasn’t been through the company’s validation testing and peer reviews, potentially resulting in unchecked vulnerabilities,” Gautam added.

An overreliance on AI coding tools may also be eroding the skills of human programmers, with research from education platform O’Reilly finding that interest in traditional programming languages is in decline.

Similarly, a post from tech blogger and programmer Namanyay Goel sparked debate on this topic recently when Goel claimed junior developers lack coding skills owing to a heightened use of automated AI tooling.

How can businesses use these tools effectively?

Despite concerns, there are clear signs AI coding tools are delivering value for both software engineers and enterprises. GitHub research from last year revealed AI coding tools have helped engineers deliver more secure software, better quality code, and the adoption of new languages.

With this in mind, firms need to prioritize certain processes to deliver success with AI tools. Flavell said businesses need to put upskilling front and center, as well as improving code reviews and quality assurance.

“It is essential that organizations create and implement governance processes to manage the use of AI generated code,” Gautam added.

“When it comes to coding, AI tools and human input will all play their part. Organizations gain the best of both worlds when they integrate these two together. Human Intelligence is essential to tailor coding to specific requirements, and AI can help experts increase their efficiency.”

MORE FROM ITPRO

• Can AI code generation really replace human developers?
• AI-generated code risks: What CISOs need to know
• The world's 'first AI software engineer' isn't living up to expectations

Java developers are encountering significant productivity barriers, according to new research, prompting businesses to take drastic measures to boost efficiency.

Perforce Software’s 2025 Java Developer Productivity report revealed barriers to Java developer productivity can take on many forms, but the most significant issue hurting their ability to work effectively was insufficient documentation (41%).

Lacking robust documentation means devs have to spend more time initially getting to grips with the code, architecture, or tools they are working with, bogging down their ability to actually get to the task at hand.

It can also feed into various further friction points when conducting maintenance and debugging, where the developer is not able to understand the previous decisions made during development and thus more time is taken to troubleshoot issues.

Communication issues between teams were also a common problem cited by businesses, with 38% of developers reporting it was hurting their productivity.

Bad communication can lead to improper implementation or developers misunderstanding the requirements of the project or feature they are working on, forcing them to spend time reworking and remediating mistakes.

Other commonly cited barriers to Java developer productivity were mismanaged timelines (32%), long redeploy times (29%), developer turnover (26%), and insufficient developer tools (24%).

Speaking to ITPro Martin Reynolds, field CTO at Harness, said many businesses face developer productivity problems. A key factor here, he noted, is that a significant portion of software developer’s time is not spent coding but on other ancillary tasks, or even simply waiting in some instances.

“About 40% of software developer time is toil not related to writing code – whether it’s waiting for builds to complete, being on call to troubleshoot, and resolving security issues,” he explained.

“A lot of the perceived productivity problems developers face stem from process inefficiencies, bottlenecks during testing and quality control, and a lack of automation across the software delivery lifecycle (SLDC).”

Development barriers strike businesses “with equal opportunity”

Generally, half of the respondents said their companies are already planning on bolstering Java teams with new developers in the coming year, but ensuring that the productivity of these expanded teams remains high is essential.

Firstly, 34% of respondents said their employer also plans on increasing their Java tool budgets this year, but how will they decide which tools are actually helpful?

When asked how they will improve developer productivity, 47% said they had been individually tasked with investigating which tools might work best, with 38% reporting they had been put into work groups for the same purpose.

This group-based approach appears more popular at larger enterprises, with the figure rising to 49% when restricted to developers working at firms with over 1,000 employees.

The most popular method to boost developer productivity was using AI tools, cited by 50% of respondents, with code completion (60%) and refactoring (39%) being the top use cases highlighted by devs.

Notably, however, 12% of respondents stated they do not use AI tools in their workflow, with a further 12% reporting that their organization was still blocking the use of AI for development purposes.

Perforce noted that giving developers access to the latest tools will help them maintain high output as other factors continue to limit their productivity.

“[Businesses] that arm their teams with appropriate tools will be the ones that will succeed working in increasingly complex development environments and demanding business conditions.”

Regardless of how businesses choose to overcome these development barriers, the report insisted they “strike with equal opportunity against businesses of all sizes”.

It added that certain approaches may help address particular challenges, others will require a more wholesale change to the organization in order to be remediated.

“While issues like insufficient documentation can easily be addressed with AI tools, long redeploy times and insufficient developer tools require a more holistic approach to realize time savings and business value.”

MORE FROM ITPRO

• Junior software developers lack coding skills because of an overreliance on AI tools
• Flaws in a popular dev library could let hackers run malicious code in your MongoDB database
• Turns out AI isn't that popular at work – just 4% of workers use the technology in the majority of daily tasks

Software security flaws are taking longer to fix than ever, new research shows, with remediation times having grown by 47% in the last five years.

Statistics from Veracode’s 15th State of Software Security report show the average time it takes an organization to fix a vulnerability has risen from from 171 days in 2020 to 252 days today.

This marks a highly concerning increase, the study warned, and nearly triple what it took 15 years ago when the annual report was first issued.

"The attack surface has become increasingly complicated, particularly in the last couple of years with the explosion of AI engineering," said Chris Wysopal, chief security evangelist at Veracode.

Alongside that, half of organizations have "critical security debt", which are flaws left unpatched or without mitigation for longer than a year. Most of those, some 70%, come via third-party code or the software supply chain.

"Our investigations provide solid evidence that organizations can drive down debt, but many need help to prioritize which vulnerabilities to tackle first," said Wysopal.

However, there is good news according to Veracode. While the volume of flaws – and high severity flaws – remains high, the overall proportion of applications failing OWASP Top 10 and CWE Top 25 tests is “steadily declining”.

"Of particular note, the prevalence of high-severity flaws has been cut in half over the last decade," the study noted.

Mind the software security gap

The average figures mask the reality that some companies are in a much worse state than others with regard to software security, Veracode found.

When it comes to critical security debt, some organizations have almost none, while others are "drowning in it", the company said. Among top performing companies, fewer than 17% of applications have flaws lasting longer than a year, while struggling organisations have older flaws in 67% of their applications.

"The gap between the top 25% and bottom 25% of organizations is fascinating," Wysopal said.

"The results raise the question of which factors account for the marked differences in how organizations manage security debt and what teams can do to tackle it."

That security gap is echoed across other metrics, Veracode noted. Organizations with more mature security approaches, which Veracode deem to be "leading", have flaws in fewer than 43% of applications, while "lagging" companies have flaws in 86% or more of applications.

The same is true for the rate of fixing flaws, Veracode noted. Leaders resolve 10% of flaws monthly, and half within five weeks, while lagging companies resolve fewer than 1% of flaws monthly and take longer than a year to fix half of spotted vulnerabilities.

Previous research by Veracode revealed that security debt was particularly challenging for the public sector, with six-in-ten applications containing unpatched flaws for more than a year, versus 42% across the private sector.

Alongside the private sector, industries including finance, healthcare, and IT were found the most likely to have serious flaws left unaddressed, according to research from Black Duck.

Software security flaws cost billions each year

Software security flaws have become a major issue for developers in recent years, alternative research shows, and it's pushing many teams to breaking point.

In IDC report on behalf of software firm JFrog found that half of developers spend 19% of their weekly hours on security-related tasks, and this is often outside normal working hours.

All told, identifying and remediating software security flaws is costing these firms a fortune, with IDC estimating organizations spend around $28,000 per developer each year on remediation.

MORE FROM ITPRO

• IT leaders need to accept they'll never escape technical debt
• NCSC CTO says what everyone is thinking about software security
• Software developers and security experts report that ‘tool sprawl’ is burning budgets

Software development leaders say their organization did not have a robust incident response plan in place to contend with disruption before the 2024 CrowdStrike outage.

A report from IT services provider Adaptavist surveyed development leaders on how their organization reacted to the CrowdStrike outage in July 2024, which affected an estimated 8.5 million devices.

The respondents came from organizations with over $10 million in revenue based in the UK, US, and Germany.

The incident has been reported to have cost US Fortune 500 companies $5.4 billion, between £1.7 and £2.3 billion to the UK economy, and affected 98% of companies according to Adaptavist’s research.

Looking back on the event, 84% respondents admitted that their organization did not have an adequate incident response (IR) plan in place before the outage.

Of those who said they did have a plan in place, only 16% reported that they were actually effective in helping them recover from the fallout caused by the event.

Adaptavist noted that most organizations had never experienced a large-scale outage like that before, or the consequences they can have on their IT operations and, as such, struggled to understand what would be required to minimize the impact of such an incident.

But the report also found that 80% of organizations claim to have drawn positive outcomes from the crisis, which brought about what it described as a “remarkable change among businesses”.

How the CrowdStrike outage forced changes in IT resilience

Adaptavist's report claimed the CrowdStrike outage “opened IT leaders’ eyes to the wider robustness of their entire software development practices and processes”.

For example, 81% of respondents said they adopted more robust software development methodologies as a result, with one-third stating they totally overhauled their engineering processes to prevent similar disruptions moving forward.

Among the list of changes leaders made to their development practices, 54% committed to IR planning, with just under half identifying monitoring and observability, unit testing, integration testing, CI/CD, and agile methodologies, as other key change areas.

Other frequent answers included manual code reviews (47%), grey box testing (47%), white box testing (46%), and system testing (45%).

In addition to operational changes, Adaptavist found the CrowdStrike outage also prompted changes in how organizations invest in software development. It reported 86% of businesses had boosted investment in software development practices and training as a direct response to the incident.

The key investment areas listed by the respondents were agile and DevOps practices and training (89%), software testing training (89%), cybersecurity training (88%), and IR training (86%).

The incident also sparked a hiring spree, Adaptavist noted, with 99.5% of organizations stating they plan on expanding their technical teams, with quality assurance roles (36%), IT operations (34%), software developers (32%), and DevOps engineers (31%) top of the list for recruitment.

Businesses still plagued by outdated development culture

Yet cultural challenges remain, the report cautioned, with 44% of IT leaders stating that their organization still prioritizes speed over quality in software development.

Furthermore, just under two-fifths of leaders said they worry that their team’s excessive workloads will lead to another major incident.

A quarter of respondents warned their organization still advocates for a culture of fear over learning to reduce risk, with 40% stating they still fear acknowledging their mistakes.

A lack of psychological safety is also hindering innovation at their organization, according to 44% of IT leaders, with 42% claiming their firm’s security is compromised by a fear of admitting one’s mistakes.

Adaptavist suggested that skills shortages are only making this problem worse, advising businesses to invest in building a culture that seeks to address burn out and stress among engineers to attract talent.

“The ongoing war for IT talent is likely exacerbating these issues, but building a culture which invites open and honest collaboration, and addresses the issue of over-worked and over-blamed teams is the key to creating a welcoming environment for more IT professionals and delivering a far more resilient, efficient and secure IT environment,” the report advised.

There are many things to do when starting a company. Find desk space, register the company, get a bank account, set up the website, and all the other tasks that require different hats to be worn. If the idiom were reality, hatters and milliners would be present at every startup accelerator. 

You quickly need a product or service to offer your customers. Without this, you won’t be in business for long, unless you already have other revenue streams or your investors or lenders are patient. Funnily enough, they never seem to be. 

You’ve probably already thought of an idea already; you think it’s going to change the world for the better, solve someone’s problem, or mitigate someone’s risk – possibly you hope it’ll do all three. So how are you going to get from A to B, where A is nothing but a headful of ideas, and B is a product in someone’s hand being used “in production”?  

We faced the same challenge when we started a company six years ago, armed only with a couple of laptops and a list of good contacts. You’ll need to work hard on networking throughout your journey – it’s hard to bring a product to life without a lot of help from others. 

Laying the groundwork

We wanted to disrupt existing practices in an area of healthcare research that aims to understand patient outcomes and experiences, outside of clinical trials, in almost any disease area. First, we needed to establish at least an outline “product-market fit”. We knew we had to ask ourselves – and answer – some very searching questions. These include: 

• Who are your customers?
• What problem(s) are you trying to solve for them?
• Do your customers even know what problem(s) they have?
• Will customers pay (and continue to pay) for that solution?
• What are they currently doing instead?
• If something already exists, how does it compare?
• How will you measure success?
• What does good look like?
• Are there any early KPIs/OKRs you can use to judge your progress?

We set out to validate our ideas by working with senior clinicians at The Royal Marsden Hospital in London, one of the world’s leading hospitals dedicated to cancer treatment and research. They helped us understand the contours of patient experience in oncology, many aspects of which extend across other disease areas too. We also ideated at length with industry experts at major pharmaceutical companies to gain insight into the types of evidential gaps they are trying to fill and where our solution could help with that.  

Finally, we checked the regulatory landscape to understand external constraints such as ethics, pharmacovigilance, data protection, and security requirements. Make sure you know who your key opinion leaders are and then ask as many questions as you can – most people are happy to have a chat over coffee, especially if you aim to improve the way things work in their industry. 

The building phase

With your assumptions challenged and your offer refined, you can move on to a highly creative and productive phase that will shape your product much further and quicker than you have so far. You need to start product iteration, which is a cycle of designing, testing, prototyping, and perfecting. Regular inspections and feedback are key to this process; as is listening. Remember the Lean methodology of “think big, act small, fail fast, learn quickly”. 

For this, we created the cheapest, quickest version of the product that we could and got feedback on it as early as possible. This way the cost of “failure” was very low, and we could easily pivot or simply remove functionality and try something new. You can find several ways to create minimally viable versions – wireframing tools help a lot here, but I’ve seen early product ideation done on paper.  

In our early user testing, we implemented clickable wireframes for mobile devices, which we chose as our initial target form factor. One version was a fully featured prototype that had the feel of a complete app but was built at a fraction of the cost. There are also now no-code or low-code solutions that go a stage further and provide basic functionality that further blurs the lines between prototype and minimum viable product (MVP). 

Asking for feedback

Who should you ask for feedback? It could be anyone: friends, family, and colleagues will all have useful thoughts. All feedback is a gift, and this is one that keeps giving. The best option is to ask your prospective end users.  

Don’t get too stuck on exactly who to ask. I guarantee the minute the rubber hits the road, you’ll start learning things you didn’t realize, or think were important yet. When we got feedback from people living with an autoimmune condition that caused muscle weakness, particularly in their eyelids, we soon realized it was hard for them to scan up and down a long screen of text or icons – we hadn’t expected that, but now it became obvious. 

We then organized phone calls, online surveys, and even in-person focus groups at venues in London, Paris, and Milan. There are many options where people can take part remotely, even remotely screen and voice-recording to get stream-of-consciousness feedback from users, but in-person testing is still important as the level of insight it provides is great.  

Choosing your priorities

When you have some feedback, organize it into areas of functionality; let’s call them “epics”, given we’re already considering an agile approach. At this point, you’ll be creating a backlog of product ideas. You can’t really expect your users to tell you which of them will provide the most value; it’s up to you to listen carefully. Find out what they’re doing now: can you imagine them switching from that to using your shiny, new application instead?  

As part of our discovery, we wanted to know if people track things about their disease already, such as medication, side effects, and treatments. If so, where do they already do that? We found quite a few people using spreadsheets to do this. If you give them your app, is there any friction in moving over to it – how likely is it to happen?  

You’re often not competing with the things you think you are, such as better features and functionality. Often you’re competing for people’s attention, the span of which is now frighteningly short. Dealing with patients suffering from acute or chronic diseases, we found users already have a lot going on in their lives and spend time managing their condition, treatments, and side effects – we usually couldn’t expect them to spend long using our app too. There are exceptions, such as a group we studied who needed regular blood transfusions which take the best part of a day in the hospital during which they had time to provide feedback. A different consideration here is hospitals are often places with restricted connectivity, which can limit the use of mobile devices. 

Finalizing your product roadmap

Finally, it’s time to review the backlog and the epics you identified. Try to arrange these into a product roadmap. There is much to cover in product management but this would be a good time to familiarise yourself with two key frameworks. 

First is the Kano Model, which helps us prioritize features on a product roadmap according to the degree to which they will satisfy users. I like this framework because it focuses on user delight while creating the biggest bang for your buck. It also explains why today’s “wow” feature soon becomes expected. 

The other model is the Design Council’s Double Diamond. This encourages you to take a two-stage approach in your thinking; initially divergent exploration, and then convergent focus. It does this across two areas called the problem space and the solution space. 

We’ve used this to great effect as a means of moderating conversations while planning our product roadmap. The idea is to prevent you or your stakeholders from jumping straight to the first solution they can think of. Taking the time to check if you really understand the nature of the problem and brainstorming for several competing solutions sounds like common sense but be prepared to explain the Double Diamond repeatedly on your journey to a successful product. 

As you can see, the process of designing, testing, prototyping, and perfecting is endless but you’ll recognize when you have something good enough.  

Our first oncology study app was quite basic, but we soon added more functionality. It’s also about removing features. Users had asked us for a feature that found people nearby with a similar stage of disease for support, but it wasn’t used as much as we had hoped. In the end, we withdrew it. Nothing in product management is an exact science and the data and feedback can only tell you so much. Don’t be precious about any of your ideas or assumptions as they will probably all be challenged at some point and your product will usually end up looking quite different when your journey from A arrives at B.

More than two-thirds (67%) of DevOps professionals have actively “slowed down” cloud native adoption due to lingering security concerns, according to a study from Red Hat. 

The report from Red Hat, based on a survey of 600 DevOps, engineering, and security professionals globally, highlighted security-related concerns as a key barrier to the adoption of cloud native technologies such as Kubernetes. 

More than one-third (38%) of respondents said that they don’t believe cloud native security is “taken seriously” enough and that security investment is inadequate. 

These security concerns represent a long-running theme in the cloud native space, Red Hat’s report noted. 

Over the past several years, adoption rates have grown rapidly amid a marked increase in cloud native technologies and heightened interest among large enterprises. 

But this growth rate is a key factor in why security concerns continue to loom heavy on the minds of engineers and security professionals, according to Fevzi Konduk, head of ecosystem market incubation at Red Hat. 

Speaking to ITPro at KubeCon in Amsterdam, Konduk said that the rapid evolution of cloud native technologies and the relative immaturity in the space are proving a key barrier to operational alignment and presenting dynamic security considerations.  

“Because the technology is evolving so fast, especially around cloud native workloads and the architecture and technology that drives that, behaviors change quite drastically,” he said. 

“This is not a saturated market, or a market that’s reached complete maturity yet,” Konduk added. “It’s still evolving and this is an underlying reason why there are significant security issues.”

Rapid development causing security headaches

A main driver of the uptake in cloud native technologies is the agility it provides to enterprises, the Red Hat study noted. 

“Faster time to market, adaptability, and reliability are all benefits of cloud native technologies and key drivers for enterprises to digitally transform their IT infrastructure,” the report said. 

However, Konduk said that because developers “are full speed ahead”, other functions within the enterprise are struggling to understand or accommodate for rapid rollout of cloud native technologies.

“The developers want to develop as fast as possible and have flexibility, but operations can’t always come up to speed and fully understand what they’re operating or consider potential security issues,” he said. 

“That’s why we talk about DevOps to try and bring this together. But it also means a major fundamental change in the process of how you do development and handle potential security scenarios,” he added. 

Greater engagement between DevOps teams and the security function was highlighted as a key necessity for organizations continuing to steam ahead with cloud native technology development, Konduk said. 

Recent research from Palo Alto Networks found that this closer relationship between vital functions is improving somewhat. 

Its 2023 State of Cloud Native Security report found that many companies are “encouraging a deeper level of engagement between application developers and security tools and teams”. 

81% of respondents said that they have embedded security professionals within their DevOps teams and have witnessed a marked improvement in their ability to identify security issues that might have previously gone unnoticed. 

Security failures cause significant business impact

Failing to adequately address potential security concerns can have a significant impact on businesses, the study found. 

37% of respondents identified revenue and/or customer loss due to a container or Kubernetes security incident. 

“These incidents could result in the delay of critical projects or product releases, as businesses must prioritize security efforts to address the vulnerabilities that were missed in the development stage,” the report said. 

This delay could have a major long-term “ripple effect” on the business, resulting in further lost revenue, customer dissatisfaction or potential loss of market share to competitors. 

“Those types of occurrences can also erode customer trust,” the study added.

Testing isn't a software developer's favourite job. The fun part is writing the code; who wants to jump through hoops that tell you just how little of it works? Nevertheless, it's a mandatory practice for good programming. It will help prevent bugs that could affect the performance of your code, make it less usable, or worse still, allow cyber attackers in through the back door.

Building testing into your programming from the beginning makes it easier and less time consuming to fix bugs, but how do you do it? For Python developers, the language comes with its own testing framework called Unittest, but there are also third-party testing frameworks that aim to improve on the original. Here's a look at some of them.

These testing tools aren't just useful on their own. You can use some of them in combination with each other. For example, Selenium is good for testing user interactions, but is at its most powerful when used with other frameworks. Because it uses Python, you can parameterize Selenium by calling it from your PyTest functions. You can also fold it into behaviour-driven development by calling Selenium from within your Behave session's steps file.

Whether you're using unit testing, behavioural testing, or both, building these tests into your coding process throughout can help to increase the quality of your final product.

Unittest (PyUnit)

As Python's baked-in testing module, Unittest's main advantage is that you don't need to install anything else to use it out of the box. It handles unit testing (as you could probably guess), which ensures that a software function produces the correct output, even when presented with unusual input.

This testing tool requires you to create a class that holds your tests by subclassing its TestCase class, like so:

You then create a function for each of your tests inside the class. You use one of its assert functions to determine test outcomes. For instance, self.assertEquals() tests whether a function's output equals your expected output. There are lots of these, including boolean assertions (testing whether something is true or false), greater or lesser, and matches for regular expressions. A newer version, Unitest2, supports more of these assertions.

One useful feature of this tool is its ability to support fixtures. These are environments that you set up to support the program. For example, you might need to log into a database and retrieve a record before you can test whether a function updates it correctly with a given input. A fixture enables you to do that.

Unittest is a great framework for writing basic tests. Its use of a class for test cases allows you to group tests that map to software features. However, it quickly gets unwieldy thanks to its insistence on inheriting tests in classes.

Nose2

Unittest's limitations left room for improvement, so third party developers updated it with their own testing framework called Nose, subsequently replaced with Nose2.

Because this testing framework extends Unittest, it can run Unittest tests alongside its own. Nose2 is extensible, providing support for plugins that give it the potential to offer more functions than unittest. It also adds another important feature: parameterisation.

Most tests need multiple inputs to be sure that no strange elements slip through. For example, if you're testing a function that validates a product price, you might want to try entering various prices with different numbers of digits. You might also want to enter other prices that might fail the test, such as 0.00, a negative price, and perhaps prices with non-numeric characters. Rather than creating a single test for each of these inputs, it would be better to make a test that could rerun itself with inputs from a list. Nose2 allows you to do this.

Pytest

Pytest is an alternative unit testing framework to Unittest and is designed for simple but highly functional testing. Even the developers of Nose2 recommend it as a good option for those new to testing on their GitHub page.

Because PyTest is a third-party open-source testing library, you must install this open-source tool before using it. One difference to Unittest is its use of functions without the need for a class. This means that Pytest requires less code to create tests than Unittest does.

Let's say we have a function to add 1 to an input:

Whereas unittest requires you to contain a test for this system in a separate class, you can simply write a test as a separate function, simplifying the whole process.

Then we use a simple assert function to test the result as a separate function in the same file:

Just as in unittest, the assert function lets you describe what a test looks like when it passes. In this case, running the function inc with an input of three should return a result of 4. If it doesn’t, then PyTest will report that the test has failed.

Pytest is also extensible and features a full plugin library.

DocTest

For an alternative method of testing code, how about writing your tests directly into your documentation? DocTest directly references your code documentation for its tests. You write your documentation as you normally would, but you embed examples of function calls with appropriate input and results within it.

You can embed these tests in docstrings at the function or module level. Then you can either invoke it at the command line or you can include instructions to run it at the bottom of your modules. Alternatively, you can embed the tests in separate .rst help files for larger documentation files.

Like Nose2, DocTest has the advantage of integrating with existing Unittest tests, and provides an elegant way of combining tests and documentation together. On the downside, however, it doesn't include fixture management.

Behave

Those tools are all useful for unit testing, where you test individual functions against basic inputs. However, they might not enable you to test combinations of functions that produce business results your users care about. A business executive might not care that a function validates a customer's login email address, but they'd like to be sure that the program lists a user's outstanding orders after they've logged in.

This is where behaviour-driven development comes in. It tests scenarios and outcomes that map closely to tasks that software users care about. These are known in development parlance as user stories.

The Behave testing library uses specification files to test these stories, which developers must write in a language called Gherkin. It defines application scenarios, and then uses a structure of steps to define the tests, such as:

The given statement sets up the environment to run the test. In this example, I log in describes that the user should be logged into the system before the test is run. The when statement then describes the condition that you’re testing (in this case, it’s testing what should happen when a logged-in user has an outstanding order). Finally, the then statement describes the desired outcome when the condition is met (the user should see their outstanding order)..

You define the code tested in these steps within a separate steps file using Python decorators. For example:

As with other testing frameworks, you can write these tests before putting together any of your code. They'll all fail, of course, until you then write the functions to support them.

The great part of behaviour-driven development is that by writing the tests, you're documenting your user requirements in a structured way up front. You can then use these tests as a guide when writing your application.

Selenium

These tools are all very well suited to testing application code running locally, but how do you relate them to user actions in browser-based applications? You might write tests to run at the controller level if using a model-view-controller architecture, as we documented in our series on Flask development, but a more useful, intuitive way to test browser-based inputs is to simulate the browser itself. Browser automation enables you to test program input from the user's perspective, and there's one go-to solution for that in Python: Selenium.

Selenium simulates a browser that you can program to automatically carry out common user actions, including entering text into web forms and clicking buttons. You do this by writing scripts in a range of languages including Java, Ruby, and Python. The script finds elements in a web page using their names or other parameters, and then takes actions on them.

Rather than functioning as a testing tool itself, Selenium is a library that you can call from within your Python testing framework of choice, such as Pytest.

For example, you might use this tool to test a form which asks for a user’s postcode and another that asks for their country. You could use PyTest to carry the relevant test data, such as ‘90210’ and ‘United States’. You’d then manipulate Selenium to enter that data into the browser by calling Selenium to find the field named postcode and then entering the postcode. It would then select the relevant country from the drop-down country list, and finally it would find the submit button and automatically click it.

Then, you’d call Selenium to interpret the browser’s output, passing it to an assert statement in Pytest so that you could compare it against your expected result.

Selenium enables you to test your program from a user’s perspective. By marrying it with parameterisation in your testing framework, you can submit dozens or hundreds of combinations to test a multitude of complex form entries and other browser interactions.

In the world of business technology, Microsoft has been a firm fixture for decades, and its flagship operating system forms the backbone of many organisations’ IT strategies. Windows remains the dominant platform used by most companies for their desktop and laptop fleets, and as such, the question of how best to manage their Windows deployments is one that many IT leaders have to grapple with.

Keeping business devices up to date with the latest Windows versions is a key part of maintaining a strong security posture, but this must also be balanced with other concerns like potential compatibility issues, as well as the planning and organisation involved in performing any large-scale migration.

Microsoft is currently in the process of rolling out Windows 11, an all-new version of its OS software, and as deployment gears up, we checked in with our panellists to find out more about their plans for upgrading to the latest version, as well as their tips for planning a smooth migration, and what influences their choice of desktop platform.

Clash of the titans

Unsurprisingly, all our panellists reported running Windows devices within their organisations. While Windows retains the largest market share in terms of business devices, the gulf between it and its competition isn’t as vast as it once was. Apple has been particularly successful in establishing a foothold with developers and engineers, and almost all our panellists reported their software developers had a preference for macOS devices.

Moonpig, for example, gives all its staff the choice between Mac or Windows machines, and CTO Peter Donlon reports that although most of the business is split, the majority of his technical staff have opted for the former.

“When you think about the amount of effort you put into hiring great people and then you pay them good salaries, why would you force them to use a tool that's suboptimal for them? For a lot of our engineers, it's a lot more efficient and comfortable to work on a Unix-based operating system,” he says. “Equally, for people in the finance team, they very well might be more comfortable and experienced with using Windows. I feel it's the job of IT to enable everyone in the business to do their best work and as such the right choices of equipment are a key part of that.”

Tempcover’s staff have a similar choice, CTO Marc Pell says, but in contrast to Moonpig, most are on Windows. Having access to a macOS device, however, is “necessary for certain app development”, Pell notes.

For Guide Dogs CIO Gerard McGovern, meanwhile, the issue is a little less clear-cut. He’s a personal user of both platforms, but points out that, for larger organisations, Microsoft has a couple of key advantages that makes Windows a more compelling option.

“I agree to a point,” he says. “For engineers, et cetera, there are clear advantages and that's why they use Macs. Personal preference is nice to be able to cater for, but Macs are more expensive and the business level support is not great, so when you have 2,000 people, those differences add up.”

Unlike Tempcover, Moonpig and Guide Dogs, Kreston Reeves does not offer its staff a choice of platforms. Instead, workers are supplied with a Windows-based HP laptop, with centralised compute resource provided by Citrix’s desktop virtualisation software, but as director of IT Chris Madden explains, this lack of choice is driven by necessity.

“We are an accountancy practice,” he says, “and some of our key software has to run on-premises as no cloud versions are available. Some examples are tax production software, practice management software dealing with time and fees, et cetera.”

“There are no real alternatives,” he adds. “Occasionally there may be an option to move to a vendor who has a cloud product, however that is arduous and involves re-training hundreds of people. That hidden training cost is quite a barrier to change. We also go for a best-of-breed approach on our specialist software so a move away may well be seen by my colleagues as a step backwards.”

Ironing out the kinks

This also governs how quickly Kreston Reeves can update its endpoints, as the software it relies on may not be upgraded to be compatible with newer operating systems for some time after their initial rollout. Waiting until the newer version is a little more mature also reduces the likelihood of bugs and instability, which is attractive for organisations with a lower risk tolerance.

For those with less reliance on specialist software tools, the decision to upgrade their fleets can be approached with more flexibility. McGovern, for example, is planning to have the majority of his users migrated to Windows 11 by February next year. Although Guide Dogs has some software that requires Windows 10 - such as programmes used in its breeding centre - McGovern says he isn’t going to let this delay the rollout.

“We are relatively simple in our requirements,” he says; “90% of our users just use Office and web apps. We've been doing testing and there are some specialist tools we have that aren't compatible, so we’ll be pausing those.”

Moonpig has also been running a pilot programme to assess any compatibility issues with Microsoft’s newest refresh, and notes that there have been one or two hiccups that may prove to be a small barrier, most notably with security products like VPN and endpoint protection solutions. However, the company prefers to keep its machines as up-to-date as possible, and Donlon says that he expects the migration to be taken care of relatively quickly.

“If the compatibility issues are resolved quickly, it could be within a month or so,” he says. “I can't imagine it being more than a few months. Ultimately our requirements are fairly simple as 99% of the software our colleagues use is SaaS. It's just making sure it's secure.”

When Tempcover does decide to migrate, Pell predicts a smooth transition, largely down to the fact that neither hardware nor software compatibility will be an issue.

“There are a couple of programs that need a Windows machine, but we have Parallels to thank in these cases,” he explains. “With Microsoft’s Mac support with tools like Visual Studio Code, we can work on the app (which is built in React Native) with ease.”

If it seems like our panellists’ migration plans for Windows 11 are somewhat lacking in urgency, that’s because they were in universal agreement that it’s distinctly lacking in must-have features. Although the need for continuing security updates means they’ll need to upgrade sooner or later, there’s very little about Windows 11 our panellists found overly compelling.

“To be honest, I’ve not found any new features worth calling out in day-to-day use, apart from the time prediction on installing Windows Updates which is a nice touch”, Pell says. “We’ll migrate users at some point next year, but we’re in no particular hurry. I wouldn’t be surprised if, in a number of cases, the upgrade coincides with a hardware refresh too - again because I’m yet to see the justification for the effort.

“We may also provide a guide and permission to perform the upgrade to staff who are comfortable to do so. We have a heavily IT-literate staff so this is a possibility with a light touch from a support perspective.”

Similarly, Madden says that he hasn’t identified any USPs for Windows 11, aside from some “low-level automation functionalities” which will be rendered somewhat redundant by Kreston Reeves’ likely deployment of Microsoft’s own Power Automate platform.

“For us, it's a better UI/UX, especially on the assistive side,” McGovern says. “The contrast options are better, there’s more audible alerts, and tweaks to magnification and text to voice.”

He adds that the overall UI is better than its predecessor, but even McGovern notes that the new OS is “more of a Windows 10 Service Pack”.

Slow and steady

With this in mind, it’s easy to see why IT leaders might want to delay the planning and execution of an OS migration, which can be a stressful endeavour if not managed correctly. Donlon’s main strategy is to gather continual feedback from test users to identify any potential issues, and McGovern follows a similar approach.

“Appoint a good project manager, build the team, engage with end users, test in small numbers, roll out gradually, learn from mistakes, feedback into process, cross your fingers and hopefully, you should be all done.”

Unlike with other software rollouts, however, user education and training isn’t a priority for our panellists when it comes to new operating systems. As Donlon points out, the gradual rate of change - particularly given the lack of new features in Windows 11 - means there’s not much to adjust to.

“In my opinion,” he says, “OS updates tend to be very incremental these days so there's not that much to learn from version to version. We do have a fairly tech-savvy organisation though, so I can appreciate that it might be different for others.”

“I would agree,” Pell adds; “it’s familiar enough not to cause staff any disruption, I would think.”

Fundamentally, desktop devices remain the bedrock upon which business IT is built, and how one manages the software that powers them will vary depending on an organisation’s priorities. Madden, for example, needs to keep a close eye on software compatibility, while Moonpig’s and Tempcover’s reliance on cloud and SaaS-based tools mean that for both Pell and Donlon, it’s more an issue of personal preference. McGovern, on the other hand, takes a more practical view.

“Whilst software is cloud based, for us the standard OS route is about providing a consistent experience,” he explains. “We can ship a laptop out and someone logs in and everything is set up. It will automatically download settings, documents etc and automatically work on a corporate Wi-Fi, VPN et cetera.”

“Our philosophy is to allow people to access from anywhere, on any device so we support nearly every scenario, but there is a difference when it's a corporate bought and supplied device. And, as well, whilst cloud apps are good, people still mostly prefer the ‘real’ Office and Teams apps.”

Twitter will expand free access to its data for software developers so they can create tools and products that promote safer online conversations or curate content.

The move is part of the social media site's efforts to decentralise its operation and put more control into the hands of its users.

Social media companies such as Twitter and Facebook have come under increasing scrutiny for apparent behavioural modification practices. Regulators and authorities are concerned with the types of algorithms they use, which are thought to prioritise negative content to keep users engaged. This is often attributed to hate speech and the spread of misinformation.

Twitter's answer is to offer more control to the users themselves, letting them curate what content they see or have new ways of sharing content on the platform.

Starting Monday, developers will be able to access data on up to two million tweets per month through Twitter's application programming interface (API) at no cost.

Developers already using the Twitter API v2 will automatically see their projects upgraded to 'Elevated' access. Or they will need to apply for Elevated access.

The social media site said it is working on a way to enable developers whose previous applications for a developer account have been declined and said it will share a path soon to enable sign up for Essential or re-application for Elevated access.

Some early examples of apps built with Twitter data include software engineer Tracy Chou's Block Party, which allows users to filter out content they don't want to see. Another app, which was built by software engineer Janique-ka John, lets users easily search for Twitter Spaces, which is the company's live audio chat feature.

"We want to continue to drive value for the developer ecosystem and make it easier for you to build, innovate, and make an impact on the public conversation," the company said in a blog post.

Huawei's long-awaited Harmony operating system, also known as HongmengOS, will be officially unveiled next week.

The event, known as the "Hongmeng operating system and Huawei's full-scene new product launch conference", is scheduled to take place on 2 June at 8 pm China Standard Time, with the second version of the operating system, Harmony 2.0, expected to become publicly available from that date onwards.

News of the event first circulated after a promotional poster for the launch event was obtained by a Huawei fan account on Weibo and posted to the Chinese social media platform, which boasts 521 million monthly active users. However, the tech giant confirmed the event details shortly after, posting an English language version of the poster onto Twitter.

The 2 June launch date comes four months prior to Huawei's complete shift away from Android, which the company is planning to abandon by October of this year. The decision had been imposed due to the Chinese tech giant being barred from offering apps and services from American companies, including Google, on its latest devices.

HarmonyOS has been tested on devices since December last year and has been in the works for over a decade. The original version of the operating system had been intended for Internet of Things (IoT) devices such as TVs, smartwatches, and smart home tech but, due to Huawei's strained relations with the US government, it's now being expanded to smartphones.

With the tech giant struggling due to US sanctions installed by the Trump administration and extended by President Joe Biden, Huawei founder Ren Zhengfei has called on the company to "dare to lead the world" in software development and exclude the US from the rest of the world.

The leaked promotional poster for the launch event comes just a day after it was reported that an internal memo sent from Zhengfei to employees revealed that Huawei will switch its focus on hardware for software development, as the sector is "outside of US control" and will provide the company with "greater independence and autonomy".

Amazon Web Services (AWS) has announced Fault Injection Simulator, a fully managed service for running controlled experiments on AWS.

Primarily used in chaos engineering, fault injection experiments subject applications to sudden stress, allowing engineering teams to observe how systems respond and implement improvements accordingly.

According to AWS, its new Fault Injection Simulator makes it easy for teams to monitor and inspect blind spots, performance bottlenecks, and other unknown vulnerabilities unidentified by conventional tests.

The tool comes with pre-built experiment templates that enable teams to gradually or simultaneously impair distinct applications’ performance in a production environment. For convenience, the simulator also provides controls and guardrails so teams can automatically roll back or stop the experiment when specific conditions are met.

What’s more, the simulator allows teams to create disruptive experiments across a range of AWS services, including Amazon EC2, Amazon EKS, Amazon ECS, and Amazon RDS. Teams can also run “GameDay scenarios or stress-test their most critical applications on AWS at scale,” said AWS.

For best results, AWS recommends enterprises integrate its simulator into their continuous delivery pipeline. Steadfast integration will enable teams to monitor and unearth production vulnerabilities constantly, improving application performance, observability, and resiliency.

“With a few clicks in the console, teams can run complex scenarios with common distributed system failures happening in parallel or building sequentially over time, enabling them to create the real world conditions necessary to find hidden weaknesses,” said AWS.

“nClouds is adding advanced chaos engineering capabilities and service offerings to our DevOps practice that will improve the resiliency of distributed service architectures we build for our customers and prove regulatory compliance,” comments Marius Ducea, VP of DevOps practice at nClouds.

“AWS Fault Injection Simulator has a deep level of fault injection that will enable us to create failure scenarios that more accurately reflect real-world events. With this capability, we expect to have an even better perspective on the expected time to recovery during real events."

Launching a website can feel like a landmark moment. It’s the digital age equivalent of hanging an ‘Open For Business’ sign in your window. If your proverbial sign is static and rarely requires updates - for example, if it’s simply intended to communicate basic operating practices like opening hours, contact information and a list of services - then you can likely build a simple site in HTML and CSS, and wrap the project there. But for most businesses, something far more dynamic is required.

As the term implies, a Content Management System, or CMS, is a structure that enables users to model, edit, create and update content on a website without having to hard-code it into the site itself. Many businesses use off-the-shelf CMS tools like WordPress, Joomla, Magento or Squarespace to handle this function.

When it comes to pin-pointing the factors that really make a really good CMS stand out, the most successful out-of-the-box solutions share one common trait - they’re easy to interpret. For any CMS, its success as a product completely relies on how easy it is for teams to create, manage and update logical data structures. The more pain-free this process is, the easier it becomes for teams to create robust content models. That being said, as any engineer will tell you, the implementation of relational databases is in itself its own art form.

The problem with these out-of-the-box solutions is that they can often include far too many features, cater to completely different levels of tech literacy, and what’s more, can make it far too easy for you to rack up an expensive bill. An alternative option is to build your own custom CMS that’s designed to meet your specific requirements.

While building the thing that you need is often viewed as the scenic route to solving your problem, when tackled the right way, it can turn out to be the quickest solution. An excellent way of streamlining a project with the potential for infinite scope-creep, while putting any information that’s lying dormant in a spreadsheet to good use, is to use Google Sheets as the foundation for your CMS.

Despite the best efforts of AirTable, Notion and even Smartsheets, there’s a reason why spreadsheets have stood the test of time as a widely accepted file format. Chances are, no matter the skill level or aversion to technology, most people within a business are going to know how to navigate their way around a spreadsheet.

In the following tutorial, you'll see how using popular JavaScript tools including the Node.js framework and React library, you can stand up a dynamic web application built right on top of Google Sheets. We’ll create a Node project to act as a container for our API queries, and then harness React to parse our data, which will then be presented and served to the user via a dynamic front-end. Here we’ll be taking advantage of React’s tendency to abstract away a lot of the internal complexities of our application’s inner workings, along with its reusable components. The latter feature is perfect if you’re building out a broad website with a multitude of pages that you’d like to all have a consistent look and feel.

For this example, we’ll be using the ‘Meet the Team’ page for a fictional technology enterprise business. If you’d like to use the example data we’re using for the purposes of this demonstration, you’ll find the spreadsheet linked below.

What you’re essentially going to do is access your spreadsheet as an API, querying it in order to pull out the content for your front-end React page. We’ll be accessing the data from the sheet in JSON format, and then using the dotenv package in order to store the credentials needed to access the information from our Node project. This will parse the information and feed it through to the front-end, presenting it in a far more polished and stylised format.

First up, let’s use the terminal to generate a new project from which we’ll be working from. Create a new directory for your project by running ‘mkdir’ followed by your project name, and then step into that directory using the ‘cd’ command. To create our Node project we’ll firstly run ‘$ npm init -y’ from the terminal, before creating two additional files we need to get up and running, using the ‘touch’ command.

One of these is our .env file which will contain any sensitive keys, credentials or variable settings we’ll need in order to access our Sheet. Remember to keep this section in your .gitignore if you decide to share your repository publicly to prevent your keys from being deactivated and your credentials from being stolen. The last step, as illustrated in the code snippet below, is to install a few external packages we’ll be using in our project. We’ve covered off dotenv, and the googlesheetsapi is no surprise. The final one is Express, which we’ll be using as our Node.js framework due to its lightweight nature and its ability to quickly spin up servers.

Once you’ve installed your external packages, open up your node project in your preferred text editor and initialise your server using the below code snippet:

Here, we’re essentially calling the packages which allow us to access the spreadsheets object, and on line six, we’re setting a variable of ‘p’ that creates a shortcut to process.env. Essentially, this will represent the state of our system environment for the application as it starts running. By adding a shortcut, we’ll be able to effectively access the spreadsheets object with far less effort.

The rest of the program is initialising our express GET route (a.k.a. how we’ll be querying our sheet) and setting up a listen function in place to assist with our build. This will give us a handy prompt as to which port the express server is running on while we’re working to connect our React front-end to the application.

Lastly, head into your .env file and assign your port number as per below in plain text, “PORT=8000” and hit save.

Run node index.js from the root in your terminal, and you should see the listen console.log message appear stating which port your server’s currently running on - in this case, it’s port 8000.

If you head to your browser and access the port that your application is running on, you’ll notice that your GET method is failing. Let’s fix that.

At the moment, we’ve got our method for querying our data established. We now need to get the data flowing through our server. The next step here is to assemble your Google Spreadsheet with both the headings and the content you’d like your node project and React app to pull through. If you’d like to follow along, feel free to make a copy of the ‘Meet the Team’ spreadsheet we’ve created.

The first thing you’re going to need to lift is your SPREADSHEET_ID. You can find this by copying the long string (or slug) found in the URL following the /d/. For example, in this case, our slug is “1f7o11-W_NSygxXjex8lU0WZYs8HlN3b0y4Qgg3PX7Yk”. Once you’ve grabbed this string, include it in your .env file under SPREADSHEET_ID. At this stage, your .env file should look a little something like this:

Next, head to the Google Sheets Node.js Quickstart page to enable the Google Sheets API. You’ll need to click the blue ‘Enable’ button before naming your project, selecting ‘Web Server’ and entering your localhost URL when configuring the 0auth values.

If executed correctly, this step will have enabled the Google Sheets API from your Google Cloud Platform (GCP) account. To confirm that’s happened, simply head over to your GCP console and you’ll spot your project in your profile page.

To authenticate this exchange of data, we’ll need to generate an API key. This will authorise your app to access your Google Drive, identify your Spreadsheet via the SPREADSHEET_ID, and then perform a GET request to retrieve the data to be parsed and displayed on your React front-end.

To get hold of your API key, you’ll want to navigate to the credentials section of the GCP console, click blue "+ CREATE CREDENTIALS" and select the "API key" option.

Once your key’s been generated, copy it and add it into your .env file under API_KEY.

Perfect! Now let’s initialise and use the key within our code to authenticate our Google Sheets query. In the snippet below, you’ll notice that we’re using the await operator to coincide with the async function initiated at the beginning of the index.js program shown earlier in this tutorial. To view the complete code as a reference, you can head here to review and even clone the repository.

Now we’ve authorised our sheets object, it’s time to minify the data. This is a process by which we remove any unnecessary, superfluous data from the JSON object, so that we’re left with only the most vital sections of the object which we’ll model within our React front-end.

Head to the index.js file of the linked repository and you’ll see how we’ve been able to do this. We start off with an empty array, and then we iterate through the rows in the sheet assigning a key corresponding to the column header, and match the value to that of the cell data for that particular row.

If you’re familiar with React, then you’ve more than likely used the package create-react-app which is by far one of Facebook’s greatest gifts to the world of application development. With one command, you’re able to spin up an instance giving you the file structure and most of what you need to get going out of the box.

The ‘create-react-app’ command generates a locally hosted, single-page React application that requires no configuration in order to get going. When you run the command, create-react-app will run local checks on your target directory, builds your package.json, creates your dependency list and forms the structure of your bundled JS files.

Let’s kick off this process by running the following at the root of our application:

If you run into any problems with the version of npm/npx that you’re running, then the below modified command with an added bit of cache clearance should steer you right:

If your command has run successfully, you’ll start to see create-react-app install its required packaged and build out the below file structure.

Lastly, you’ll notice that your application now has two package.json files. We’ll need to make an edit to the scripts section in the root, and then add one line below the ‘private’ section of your client directory. This is so that you can fire everything up with one simple command - the eternal saviour that is npm start.

In your root:

And in your client:

Now with one run of npm start you’ll be met with your React front-end pulling through information from your Google Sheets CMS.

If you check out the back-end server (running on port 8000) in your browser, you’ll be met with a JSON object displaying your CMS data in its raw, unformatted form.

But, more importantly for the many stakeholders eager to access your newly-built site, here’s what you’ll see displayed on the front-end.

What was once entries on a spreadsheet, is now a fully-formatted, somewhat shiny React web app, ready to be deployed through your favourite hosting service. The great thing about this solution is that it can be incorporated into your wider React-based application, and styled using one of many free themes and templates out there, meaning that your final output can actually scale with you. There you have it - yet another reason to love spreadsheets.

England’s new, decentralised version of its contact-tracing app will enter its public trial phase today, two months after the previous app was scrapped by Test and Trace programme head Baroness Dido Harding.

The new contact-tracing app, based on Google and Apple’s jointly-developed API, is being trialled on the Isle of Wight, although it is already in use in other regions of the UK, such as Northern Ireland, and in countries across the EU.

The model was the initial choice of software at the beginning of the coronavirus pandemic, until it was snubbed by the government in late April in favour of a centralised model. This was also trialled on the Isle of Wight in early May, before being cancelled a month later after it was discovered that the app could only pick up 4% of other iPhones it came in contact with.

The new software has been designed to monitor distance between people with the help of their smartphones, alerting users if they had been in close proximity to another person for a set period of time which could heighten the risk of contagion. If one user later tests positive for COVID-19, the other person is to be alerted to the fact even before they begin showing symptoms, lowering the chances of passing on the virus to others.

What is more, users who go out to public places, such as pubs, will also be asked to scan a QR barcode upon entrance, in order to make it easier to later alert them if they had visited a location linked to multiple infections.

Unlike the previous, centralised version, Apple and Google both claim their API is able to pick up 99% of smartphones it comes in contact with.

However, the new app is already facing significant challenges. One such issue is faulty distance estimates, which translates into smartphones wrongly recording users standing within 6 feet of one another. This could lead to a higher number of contagion alerts being sent, forcing users to isolate when there is no need to do so, as well as potentially causing emotional distress.

Even if the issue is resolved and the app positively passes the trial, the date of the rollout is not yet known. IT Pro has attempted to contact the Department of Health and Social Care to see how long the trial will last and whether the app is still estimated to launch in winter.

Microsoft customers have reported experiencing massive spikes in their CPU activity after installing the most recent Windows update.

Canny users who monitored their Task Manager said their Cortana process had started using up to 40% of the CPU's power following the patch.

The spike in CPU usage will not only tank the performance of a computer, but also the battery life if working on the move.

Irked Windows users have taken to online forums such as Reddit and the Windows 10 feedback hub to voice their frustration, but so far have been met with silence from Microsoft.

"It took MS over two weeks to fix this month's broken Visual Basic apps and now this," wrote one user. "On to waiting next month's patching round, I guess. Goddamn garbage quality control," they added.

Across the forums, users are reporting anywhere between 10% and 90% CPU increases, with the average being around 30%.

The same issues were found in the update's beta phase testing, however, Windows Insider testers claim their reports were ignored by Microsoft, according to Windows Latest.

The official Microsoft page for the update, known as OS Build 18362.329, still doesn't acknowledge the issue in the 'known issues' section.

Instead, it reads "Microsoft isn't aware of any other issues with this update," at the time of writing.

Microsoft did not reply to IT Pro's request for comment at the time of writing.

Fortunately for those affected, there is a workaround for the performance-guzzling problem. One way to is to delete a Registry Key to prevent the Start Menu from sending local search queries to Bing.

Playing around with Registry Keys isn't something that the everyday Windows user should be doing, as deleting the wrong one could lead to serious problems that may require a fresh Windows install.

One savvy user noticed the issue may stem from a cache folder located at: c:\Windows\SystemApps\Microsoft.Windows.Cortana_cw5n1h2txyewy\cache\ - which caused Cortana's initialisation process to loop continuously.

Renaming the cache folder and copying one's old cache folder from a backup of the previous Windows release (if you have one) would also solve the issue.

Users can also uninstall the update and revert to a previous Windows version if they feel uncomfortable editing the Registry and/or don't have a backup of their system before updating.

Small businesses and home users with Windows 10 installations older than a year will be automatically upgraded to the May 2019 Update to avoid systems falling out of support in November.

Despite widespread concerns over the way Microsoft implements its biannual operating system (OS) upgrades, Home and Pro users will be automatically kicked into using version Windows 10 1903, issued just a couple of months ago.

Microsoft outlined plans to implement the feature in April as part of sweeping changes to the way that updates were rolled out to users. These were in response to several disasters the company endured phasing in previous flagship OS upgrades, in particular the April 2018 and October 2018 Updates.

The firm would conventionally initiate updates on Windows 10 machines automatically once its data suggested users would enjoy a frictionless experience.

But with the May 2019 Update, users were instead notified when the upgrade was available and could choose to install the new iteration as and when they wanted. This could only be deferred for up to 35 days, however.

In Microsoft's official documentation for version 1903, the company said machines running the April 2018 Update will have the update process started for them automatically because this iteration will stop receiving updates from 12 November this year.

"Our update rollout process takes into consideration the scale and complexity of the Windows 10 ecosystem, with the many hardware, software, and app configuration options users have, to provide a seamless update experience for all users," the documentation said.

"We closely monitor update feedback to allow us to prioritise those devices likely to have a good update experience and quickly put safeguards on other devices while we address known issues."

The company has also suggested that commercial customers running earlier iterations of the OS begin the targeted deployment process to upgrade to version 1903.

Meanwhile, as part of the release schedule, updates are being supplied to businesses as well as consumers through the same channel. Windows Update for Business will feature a fresh user interface (UI) and behaviour to reflect the policy change, with future upgrades issued through a single semi-annual channel (SAC) deployment.

For version 1903, however, devices not yet configured to be ready for SAC deployment will have an additional 60 days deferral as an option beyond the existing deferral period their organisations have implemented.

Organisations that have set no deferral period whatsoever, therefore, will begin receiving the May 2019 upgrade to their devices from 23 July 2019.

Microsoft will block users with external USB storage devices or SD cards plugged into their machines from taking up the latest flagship Windows 10 upgrade.

The May 2019 Update, due to be released within weeks, has sustained an "inappropriate drive reassignment" error, the company confirmed in support documentation.

As a workaround for this glitch, the developer is blocking users from upgrading entirely if they are actively connecting USB devices or an SD memory card. But this glitch may not just affect removable drives, but internal hard drives too in some cases.

It will, however, only affect users with a Windows-10 machine running either the October 2018 update, version 1809, or its predecessor version 1803, dubbed the April 2018 Update.

Both major upgrades to the Windows 10 operating system (OS) suffered from torrid rollout experiences, each exhibiting their own individual issues when they were released.

The previous update, in particular, deteriorated Microsoft's reputation somewhat with the firm withdrawing, then releasing the package several times.

Microsoft says the issue will be resolved in a future servicing update for the OS, with the issue resolved in some current builds for Windows Insiders.

Earlier this month Microsoft launched a conscious effort to address its recent upgrade disasters head-on with a set of significant changes to the way updates are released.

Starting with the May 2019 Update, due on 10 May, users will be notified when the update is available to download and install, as opposed to the package being pushed to a user's machine automatically.

Users can also defer the major upgrade for up to 35 days while continuing to receive security patches.

Among the new features in version 1903 are a simplification of the Start menu, better search functionality, and an expanded security centre.

Microsoft is also rolling out a Windows Sandbox' mode, which can allow enterprise users to create a virtual machine-like desktop environment to run any potentially harmful software without risking the health of their device.

IT Pro approached Microsoft for more information on the nature of the inappropriate drive reassignment bug.

Microsft will overhaul the way it deploys its biannual Windows 10 upgrades in light of the high-profile April and October 2018 Update disasters.

Conventionally, Microsoft would initiate updates on Windows 10 machines automatically once its data indicated that users would enjoy a safe and frictionless experience. But starting with its next major flagship upgrade version 1903, which will be released on 10 May, users will instead be notified that the update is available to download and install.

Moreover, these big feature updates can now be initiated independently to essential security updates downloaded via the check for updates mechanism. Updates can also be deferred for up to 35 days.

This is in addition to several major changes around the processes Microsoft employes to ensure development and release goes smoothly. This includes an extended preview stage, and added machine learning capabilities to flag any potential issues.

A public Windows release health dashboard, meanwhile, will communicate key decisions clearly and frequently, according to Microsoft. This interface will resemble the Windows 10 Update History page, but features near real-time information on the rollout status and known issues across both major and minor updates.

"We believe the steps we've taken provide Windows customers more choice and control on updates while continuing to enhance our focus on quality," said Microsoft's corporate vice president Mike Fortin.

"With a more robust and longer Release Preview and further investments in machine learning for both high-severity issue detection and our next generation of intelligent rollout, our goal is to provide the best, transparent Windows update experience."

Microsoft hopes the May 2019 Update will mark a step-change from the notoriety gained following the April and October 2018 releases, which were collectively riddled with several catastrophic bugs and deployment troubles.

Last spring's release, version 1803, caused a handful of machines to experience the infamous 'blue screen of death', or sparked reboot problems, within 24 hours of installation.

This pales against a litany of issues users encountered with October's version 1809, the most significant being a critical file-deletion bug. These errors led Microsoft to suspend its initial deployment, then later re-releasing the update, suspending it a second time, releasing it for Windows Insiders, then making it publicly available a third time in mid-November.

But this third release was only available for users to manually download themselves by checking for updates, with Microsoft not deeming the upgrade safe enough to deploy automatically until just last week.

The May 2019 Update will become available in its release preview stage from next week, with Windows Insiders gaining access to the new features over the next month. This will then become generally available to Windows 10 users via the new 'download and install now' mechanism from late May.

Microsoft has recommended that IT administrators begin validating the apps, devices and infrastructure used by their organisations to ensure they work well with the release before deploying version 1903 broadly.

Months after releasing the first iteration of the botched October 2018 update to Windows 10, Microsoft has designated version 1809 safe enough to release to businesses through its servicing channel.

This major upgrade to the firm's flagship operating system, Windows 10 version 1809, was initially made public in early October last year. But it was recalled and re-released several times over the following months due to a swathe of critical errors.

These include reports of incompatibility with drives, reduced battery life, and a severe file-deletion bug. Further glitches were detected after Microsoft pulled the release and made it available to just Windows Insiders, including a second file-deletion bug that affected compressed ZIP folders.

"Based on the data and the feedback we've received from consumers, OEMs, ISVs, partners, and commercial customers, Windows 10, version 1809 has transitioned to broad deployment," the company said.

"With this, the Windows 10 release information page will now reflect Semi-Annual Channel (SAC) for version 1809. We will continue to communicate for future releases the transition from targeted to broad deployment status."

Although version 1809 was made publicly available again in November, users could only upgrade to the latest version of Windows 10 by manually checking for updates, or via external media.

The company said at the time it would learn from its mistakes in the way it rushed the April 2018 update, and take a phased approach to releasing the October upgrade. And only now has version 1809 been finally declared safe enough for broad deployment across its consumer and business user base.

This decision has incidentally been made just weeks before Microsoft is set to release its next massive upgrade, known as the April 2019 Update, or version 1903.

In the wake of its recent string of upgrade disasters, Microsoft has also begun early testing elements due to be released in a major 2020 upgrade. This was despite testing for the October 2019 update having yet to be commenced at the time of writing.

Microsoft has begun testing an in-browser security tool for Chrome and Firefox that serves as a 'sandbox mode' which lets users safely access untrusted websites without fear of infecting their machines.

The Windows Defender Application Guard extension, which already exists for the Edge browser, automatically redirects websites that haven't already been whitelisted to an isolated 'sandbox' environment. This effectively disconnects the browsing session from a user's physical machine and its data and files.

Just as it works on Edge, the extension checks the URL against a list of trusted sites defined by an organisation's enterprise administrator and guides a user to an isolated session. Users can then use this session to freely browse any non-white listed sites without fear of sustaining an infection.

Microsoft is now testing the feature before rolling this out as part of its next major flagship update for Windows 10, dubbed 'April 2019' or 19H1. The extension is currently online live for Windows Insiders, and users will need Windows 10 Pro or Enterprise installations to use the feature when it goes live in Spring.

The browser extension works based on an organisation's group policy, meaning once it's established by a network administrator it can be applied on devices across an entire company. The tool can also be configured by network isolation or application, according to Microsoft's guidelines.

When installed and fully deployed, users will see a Windows Defender Application Guard landing page when they open either Chrome or Firefox. Then, during the normal browsing experience, non-whitelisted URLs will open in a new Application Guard window. Users can also initiate a sandbox session themselves by toggling a switch in the menu settings.

However, the extension won't open this 'sandbox' session in a user's native browser of choice, i.e. Chrome or Firefox, but on an isolated Edge tab, meaning they will be forced into using Edge when browsing untrusted sites if their organisation implements the tool.

The extension is among a suite of security features Microsoft has been developing for enterprise users. Microsoft has also recently extended the idea of 'sandboxing' the user experience to desktop browsing, with this idea making its way into a future feature for Windows 10.

The Windows Sandbox desktop tool, which is currently being tested, will launch enterprise users into a virtual machine-like desktop environment when running suspicious software.

It will allow users to run applications in a clean Windows 10 installation in a windowed application, without having to run a fully-fledged virtual machine, eliminating the risk of opening potentially malicious apps on a work machine.

Google released the beta version of Android P, the ninth installment of its mobile operating system, as well as the second developer preview of the upcoming Android version at the I/O Conference in California.

Google's goal for Android P is to streamline the user interface so that customers can easily find and use apps and complete tasks. Using Project Treble, which rolled out with Android Oreo in August 2017 and simplifies updates and patches, Android P will offer an array of new features.

Latest Android P News

02/08/2018: Android P developers plot battery power boost

Two of the engineers involved in the Android P build have revealed their plans for boosting the power and efficiency of the Android P platform when it comes to battery life.

Benjamin Poiesz, group product manager for the Android Framework, and Tim Murray, a senior staff software engineer for Android spoke to ArsTechnica about why they were so enthusiastic to make the battery last longer on smartphones using Android P and how they track the data to make better decisions about how power is distributed across applications.

After reading an article on the website about the Snapdragon 810 processor on Android back in March 2015 and how it runs "really hot", Murray explained how he was adamant to fix that. So he, alongside members of the kernel and framework team started looking into how they could control the processes from Activity Monitor.

"We started enforcing affinity controls using the knowledge in activity manager service," he explained. "We started off really simple, so background services and cached apps could only run on little cores. Foreground services could use some big cores, but not all of them, and the app you're currently interacting with can use any core."

He added that the results were astounding and increased the performance per watt by double digits. When it came to developing Android P, Google essentially super-charged that process and extended the way it ran to include apps that worked when the screen was off rather than when the device was being used. The result of the Android teams' efforts was adaptive battery.

"In P, what we did was, when you turn the screen off, these kinds of system services get moved to a more restricted CPU stack. So, rather than being able to use all of the little cores and some big cores, we just restrict them to only using little cores, and it saves some battery."

This means when the screen is switched off, it uses power more efficiently. But identifying the processes that need to work while the screen is switched off versus those that still need to run was vital in the tech's development.

"So, adaptive battery was one of those ones where we're trying to get better and better predictions about what we think you're going to be using, so then those things can be allowed to run more, and the things that we don't think will be used, we're deferring them.

Now Google is working on refining that even further, using the anonymised data it collects from the majority of Android devices in active duty. Many of these changes will just be bug fixes, because bugs cause battery degradation, but a major contribution will also be getting the balance right between wake and asleep time and splitting deep doze and slight doze to save even more battery power.

Release Date:

As of 8 May, the Android Beta Program offers a download of Android P to receive feedback while the version is still in development. Six top partners will release the Android P beta: Sony Xperia XZ2, Xiaomi Mi Mix 2S, Nokia 7 Plus, Oppo R15 Pro, Vivo X21UD and X21, and Essential PH1. Pixel devices can also be enrolled and will automatically receive Android P updates.

Google released the second Android P developer preview on 9 May at the I/O conference. The first preview released in March 2018, and three more previews are expected in June and July.

We don't expect to see the completed version until August 2018, based on the release of the last iteration, Android Oreo.

Android P name predictions:

Google has a tradition of naming its Android devices after chocolates and other treats -- so what will this latest iteration be named? Spring 2018 wallpapers on Google's Instagram stories hints at the name "Android Popsicle".

Other predictions include pancake, parfait, pastry, peanut brittle and pumpkin pie. Any Harry Potter fans might be looking out for an Android Puking Pastille, though the name would be a mouthful - and not a delicious one.

Android P top features:

Enhanced Security

The OS has created a standardised biometric authentication process to handle fingerprint, iris and face recognition across such sensors found on Android devices. For apps, this makes it easier for developers to use Android P's biometric authentication prompt rather than be forced to create their own.

A new KeyStore type called StrongBox provides developers with APIs to set which cryptographic keys they wish to protect with hardware level security often found in tamper-resistant hardware featuring isolated CPU, RAM and flash storage.

Organisation

The new App Actions predicts what users want to do next and will suggest apps to assist with that task. When you plug in headphones, for example, the app will offer the opportunity to return to your last Spotify playlist. This function can be utilised by app developers to gain visibility for new apps or reignite interest in existing apps.

Slices provides templates for user interfaces, with support for toggles, scrolling content and other interactive functions. Through Android Jetpack, a set of app-building tools, developers can reach users across 95% of Android devices.

Simplified system navigation also enables access to Home, Overview and Google Assistant from any screen. Among other new gesture modifications, a tap takes you to the home screen and a swipe up reveals Overview, where you can see your recently used apps. While these movements could take some getting used to, Google maintains that expanding gestures will make multitasking and app discovery easier.

Extended Battery Life

Google pulled smart technology from its AI research company DeepMind to create Adaptive Battery.

Adaptive Battery optimises battery use through machine learning that allocates the most battery to your most important apps. With Background restrictions, you can also see which apps are draining all of your battery and restrict those apps to the most basic and least battery-guzzling functions.

Sound and Visuals

The second preview allows developers to see what their apps would look like with two notches - identical cutouts at the top and bottom center of the screen, which some reviewers are not happy with as it cuts into the screen real-estate.

On the bright side, Dynamics Processing Effect lets developers improve sound quality in their apps and adapt it to user preferences.

For users themselves, other benefits include Adaptive Brightness, which learns the level of screen brightness you like to have in differently lit situations and changes your phone's brightness automatically and accordingly; a Magnifier widget is also present to easily select and enlarge text.

Wellbeing

A series of apps and automatic functions are geared towards helping you spend less time on your mobile device. Android P will have stats on things such as how many notifications you receive, how many times you open your phone and how much time you spend on each app.

It is also preprogrammed to turn on Do Not Disturb when you turn your phone's screen over and activate Night Light mode when it gets dark to help you go to sleep.

Enterprise Adoption:

Whether you're participating in beta testing or following reactions to the developer previews, you might be considering how the Android P could help your business.

In the workplace, reinforced security can give you peace of mind for your important information, while adaptive battery, gesture navigation and App Actions can improve efficiency and extend the battery life of your device.

As a developer, App Actions and Slices bring visibility to your apps, and many of Android P's other new features allow you to optimise apps for customer preferences.

Image: Shutterstock