devopsy.kinsta.cloud

Category: Features

Survey: Cyberattacks Aimed at Software Supply Chains are Pervasive

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

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

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

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

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

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

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

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

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

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

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

February 12, 2024
Five Great DevOps Job Opportunities

DevOps.com is now providing a weekly DevOps jobs report through which opportunities for DevOps professionals will be highlighted to better serve our audience.

Our goal in these challenging economic times is to make it easier for DevOps professionals to advance their careers.

Of course, the pool of available DevOps talent is still relatively constrained, so when one DevOps professional takes on a new role it tends to create an opportunity for others.

The five job postings shared this week are selected based on the company looking to hire, the vertical industry segment and, naturally, the pay scale being offered.

We’re also committed to providing additional insights into the state of the DevOps job market. In the meantime, for your consideration:

LinkedIn

Hanwha Vision America
Santa Clara, California
Senior DevOps Engineer
$160,000 to $200,000

Indeed.com

Tecton
Remote
DevOps Engineer
$156,000 to $231,000

CareerBuilder.com

The Pokémon Company International
Redmond, Washington
Senior Technical Program Manager – DevOps
$151,000 to $189,000

SimplyHired.com

JP Morgan Chase
Jersey City, New Jersey
Lead Software Engineer – FinOps/DevOps
$147,200 to $215,000

Dice.com

XTIVIA
Remote
Senior DevOps Engineer
$120,000 to $140,000

February 12, 2024
GitGuardian Allies With CyberArk to Better Protect App Secrets

GitGuardian this week revealed it has allied with CyberArk to streamline secrets detection and management by making it easier to share insights.

Ziad Ghalleb, product marketing manager for GitGuardian, said the two companies have integrated their respective platforms using open source software that integrates GitGuardian Secrets Detection and CyberArk Conjur Cloud, a software-as-a-service (SaaS) platform for managing and rotating secrets as needed.

In addition, CyberArk Conjur Cloud is now integrated with HasMySecretLeaked, a tool for discovering if a specific secret has been exposed on GitHub. That capability enables DevSecOps teams to periodically cross-reference secrets and credentials against a private database of secrets known to have been publicly exposed.

GitGuardian claims to have uncovered more than 20 million publicly exposed secrets on the GitHub repository. While GitGuardian provides tools to discover exposed secrets, organizations rely on the CyberArk platform to manage secrets and remediate issues that arise when they are left exposed.

The immediate challenge is to find ways to integrate secrets detection within the context of larger ecosystems, said Ghalleb. In the longer term, GitGuardian is working toward embedding its tool into integrated development environments (IDEs) to surface exposed secrets as developers build software, said Ghalleb.

Naturally, there is a lot more focus on secret detection, and secrets management is getting more attention as more organizations review their software supply chain processes in the wake of a series of high-profile security breaches. For many organizations, however, it’s still early days as far as adopting DevSecOps best practices to secure those software supply chains, but it’s clear more responsibility for application security is shifting left toward developers and the DevOps teams that support them.

Unfortunately, too many developers still hard-code secrets in plain text into applications to create shortcuts as software is developed. Many forget to remove those secrets before an application is deployed in a production environment. Once an application is deployed in a production environment, it may be months before anyone discovers an issue—if it’s discovered at all.

In the meantime, cybercriminals are becoming more adept at using scanning tools to discover secrets and then exploiting them to compromise applications after they have been deployed.

Hopefully, DevOps teams will implement DevSecOps best practices to address those issues before any fines are levied. But the challenge, as always, is ensuring application security without adversely impacting the rate at which software is currently being built.

It’s only a matter of time before more stringent regulations require organizations to revisit the security of software supply chains. Countries around the world are drafting legislation that would hold organizations much more accountable for the security of the applications they build and deploy. As more fines are eventually levied, the tolerance for leaving secrets exposed in applications is only going to decline.

Secrets discovery and management is, of course, only one aspect of application security, but the more these issues are addressed before applications are deployed the less stressful cybersecurity becomes.

February 9, 2024
Cisco Extends Scope and Reach of Observability Platform

Cisco this week expanded the scope of its observability platform by adding predictive and generative artificial intelligence (AI) capabilities along with log analytics and a Core Web Vitals tool to make it simple to ensure web pages don’t lose their search engine ranking because of poor user experience.

In addition, Cisco is now leveraging extended Berkeley Packet Filters (eBPF) in the kernel of Linux operating systems to provide visibility into Kubernetes workloads and a session replay capability for cloud-native applications. In addition, Cisco has allied with Komodor, a provider of a Kubernetes management platform, to gain additional visibility into these environments.

Cisco also added digital experience monitoring (DEM) capabilities based on real user monitoring (RUM) and the full-stack observability it provides following its recent acquisition of Accedian, a provider of an analytics platform for monitoring end-user experiences.

Finally, Cisco added a Data Security Posture Management (DSPM) Observability module to the company’s Business Risk Observability platform based on the same core platform.

Announced at a Cisco Live EMEA event, these latest updates are part of an ongoing Cisco effort to extend the reach of its observability platform well beyond DevOps workflows.

Gregg Ostrowski, executive CTO for Cisco AppDynamics, said as part of that effort, Cisco is making it simpler to aggregate telemetry data for the AI for IT operations (AIOps) capabilities it provides by pulling directly from platforms such as Cisco ThousandEyes and Cisco DNA Center as well as from third-party partners such as VMware, Zabbix and ServiceNow. Similarly, Cisco is now leveraging eBPF to collect data from Kubernetes environments.

Ostrowski added that the overall goal is to reduce the amount of instrumentation effort that IT teams would have to undertake to instrument highly distributed IT environments.

There will still be a need to instrument applications, but the collection of telemetry data from the underlying IT infrastructure environment is going to be increasingly automated, he noted. In the meantime, it’s become less expensive to instrument applications using open source OpenTelemetry agent software, added Ostrowski.

In general, Cisco, in addition to enabling organizations to rationalize existing tools, is also making a case for improving collaboration by, for example, making use of natural language capabilities enabled by generative AI to launch queries and provide summarizations.

At the same time, Cisco is partnering to add additional capabilities, such as the ability to monitor machine learning algorithms via an alliance with Aporia and AS/400 systems via an alliance with Perform IT.

Ultimately, Cisco is betting that observability across the entire enterprise IT environment is going to become more unified as organizations increasingly look to correlate business processes with specific IT events, including indications of cybersecurity breaches. It’s not clear how far down that path enterprise IT organizations are just yet, but given the total cost of observing and monitoring IT environments today, there is more pressure than ever to find more cost-effective approaches to holistically managing IT. The challenge, as always, is unifying all the existing fiefdoms in IT organizations that have already embraced a wide variety of tools and platforms they are hesitant to give up.

February 9, 2024
Scrimmage for Control: On-Premises Vs. SaaS in the Observability Super Bowl of 2024

Observability means data. It encompasses a set of practices and tools designed to track the performance and health of software applications, providing insights into the “why” behind system behaviors, not just the “what.” At its core are data pillars we’ve learned how to work with and hopefully get the most out of—metrics (quantitative data on system performance), logs (recorded events within the system) and traces (detailed views of request paths through the system) that offer a comprehensive view of the system’s operation in real-time. SaaS is where the industry has been turning towards for the past decade. It’s easy to operate and upgrade and takes away maintenance and manpower requirements.

But, using a SaaS solution where data is stored on the vendor’s infrastructure can be compared to playing a football game at your opponent’s home field. Your team does not own the field and must play along with conditions that are outside their comfort zone. While your team can still strategize, execute plays and score points, the control over the playing environment, including the surface, lighting and even some rules, lies with the owner of the stadium (in this case, the SaaS vendor).

You don’t get the home-field advantage and the comfort of your familiar surroundings, and you also can’t control the audience’s shouts and cheers in the stands across the arena.

Just as a visiting team must trust the host’s management of the stadium and adapt to its conditions, organizations using SaaS solutions entrust their operational data to third-party vendors. They must trust its data protection policies and privacy agreements to ensure that the organization’s data is handled securely and in compliance with relevant regulations.

And even more importantly, they have to adhere to its hosting costs.

Let’s Leverage the Home-Field Advantage

The alternative is clear: While playing on your own field, you, the coach—hell, the entire team—know this field by heart, and you know best how to keep and enforce your own rules.

Just as a football team controls the ball and decides on the play, having on-premises data means a company or organization keeps its data within its infrastructure, offering direct control over its storage, management and security. The organization decides how to deploy, use and protect this data and even how to manage the tradeoff of data costs.

The downsides? Playing on your home field at all times means you’re running slower than the world out there. You’re not quick to update your software to the newest common practices and you’re tasked with maintaining another stack—your observability stack—on top of building your product, which serves your users.

There’s Another Way. Play the Data on the Scrimmage Line

In football, the scrimmage line is the imaginary line across the field where the ball is placed at the start of each play. This line serves as the point of engagement between the two opposing teams, with specific rules governing how players can position themselves and how the play begins.

What if we can keep the data on-premise, in the home field, a little like having the ball on our side of the scrimmage line, within our team’s possession and control? We have the ball, and we decide and strategize how to advance the ball or score from the position behind the scrimmage line, but we can still interact with the outside world (or the opposing team) under a set of rules to which we both adhere.

This is exactly where observability solutions are heading: A combination of the advantages of SaaS—easy to update and maintain value, with an easy way to distribute the solution inside the organization, alongside the advantages of on-premise—data privacy, data control and full transparent and controllable data costs.

I call this approach inCloud. It is a modern on-premises approach—data in your cloud environment, protected and controlled by the user, but still governed, managed and served with a guaranteed SLA just like the best SaaS offerings out there.

Just like the scrimmage line in football that provides a clear boundary and set of rules for how the game is played, inCloud acts in a similar way. Data is kept on-premises, allowing the organization full control over retention, privacy and data integrations. And on the other hand, inCloud defines a set of strict rules under which a control plane is allowed to operate and pass the scrimmage line, or past the organization’s cloud borderline, to manage and access the data like a SaaS solution does best.

So when we sit down to watch the Super Bowl this Sunday—let’s use that halftime show to think about where we’ll be taking our organization’s observability capabilities in 2024. Will the data be in our hands, crossing that invisible scrimmage line? Or will we lose to our opponent’s home-field advantage?

May the best team win.

February 9, 2024
F5 Looks to Streamline Application Networking

At its AppWorld 2024 conference this week, F5 announced a software-as-a-service (SaaS) edition of its NGINX application networking portfolio, which are now all available under a single enterprise license.

Shawn Wormke, general manager for NGINX, said NGINX One will eliminate much of the friction enterprise IT teams currently encounter when implementing NGINX Plus, NGINX Open Source, NGINX Unit, NGINX Gateway Fabric and the Kubernetes Ingress Controller the company provides.

As part of that effort, F5 is also now making available a unified console across its application networking portfolio that promises to streamline the management of the F5 application networking portfolio.

Currently available under an early access program, NGINX One creates an as-a-service platform through which enterprise IT organizations can invoke and pay for these capabilities on an as-needed basis, said Wormke. The overall goal is to reduce the total cost of application networking by eliminating the need for IT teams to integrate the various elements of NGINX One on their own, he added.

In general, application networking has become more complex with the rise of cloud-native applications based on microservices. By reducing the cognitive load required to network those applications, it becomes simpler to make network operations a more natural extension of DevOps workflows, noted Wormke.

Most organizations have some level of experience with application networking using proxy servers, but as application environments have become more complex, the need for gateways and ingress controllers to provide these capabilities at scale has become more apparent. As a result, more IT organizations are starting to revisit how they are structured. There may always be a need for dedicated networking specialists to manage the physical network underlay, but as other networking services become more integrated with DevOps workflows, responsibility for some networking services is starting to shift further left toward DevOps teams that will either deploy these capabilities themselves or take advantage of a SaaS platform such as NGINX One. The overall goal is to be able to dynamically provision application networking services without having to wait for a network administrator to provision them.

There are, of course, a lot of approaches to application networking that are now emerging. Regardless of how application networking evolves, however, the rigidity that has characterized the delivery of network services for decades should finally start to fade away. Today, outside of a cloud computing environment, it’s still common for IT teams to provision virtual machines or Kubernetes pods in hours only to wait days or even weeks for network connectivity to be provisioned. As IT environments become more hybrid and more workloads are pushed to the edge, there is a clear need for a more agile approach.

Each organization will need to decide how best to approach application networking across legacy monolithic applications, microservices and event-driven applications at a time when IT environments have become much more complex to manage. The challenge, as always, is reducing as much friction as possible without unduly raising the total cost of IT to a point where it becomes unsustainable.

February 8, 2024
How GitHub Approaches Internal Developer Experience

Developer experience (DX) has been the talk of the town, and for many reasons. Quality DX is intrinsically tied to increased productivity, velocity and developer happiness. Organizations that invest in DX tend to see efficiency improvements and less employee churn, contributing to reduced costs.

As such, much effort is being placed on ways to improve the experience developers have with their internal workflows and tools. But what are some good models of developer experience in practice? For that, let’s turn to GitHub.

GitHub, the ubiquitous code repository and version control platform, is naturally a developer-favorite tool. And internally, GitHub is constantly seeking to improve the experience its own developers have in building, deploying and maintaining software. Below, we’ll explore how GitHub approaches DX and instills these traits into its software development culture.

Allocating Time For Deep Work

The most crucial practice GitHub takes is allowing developers to enter the flow state and stay there. Dr. Eirini Kalliamvakou, staff researcher at GitHub, defines “deep work” as time blocked off intended for focus. “During that time, you experience as little interruption as possible,” she said. According to Kalliamvakou, employees at GitHub actively block off time for deep work — some teams even have “no-meeting Thursdays.”

There is research to support the benefits of allocating time for deep work. As I previously covered, one internal study of Microsoft employees found that developers who formally set aside focus time for coding experienced a significant boost in overall satisfaction and perceived productivity.

More recently, GitHub partnered with research group DX for a study, DevEx In Action, that assesses the observable outcomes of improving developer experience. Impressively, the results found that developers who dedicate significant time to deep work enjoy a 50% productivity boost.

Using AI Pair Programmers

It will come as no surprise that developers at GitHub dogfood GitHub Copilot, the AI-powered code completion tool built on OpenAI’s Codex. According to Jon Peck, senior manager, developer relations & enterprise advocacy at GitHub, Copilot is truly integrated into most of his daily tasks. “Copilot lives with me in any development environment I’m using,” he said.

Nowadays, the technology can enable complete, viable functions that are contextually and stylistically aware, he said. Furthermore, Copilot Chat now integrates into Jetbrains and VSCode, bringing it closer to the programmer’s accustomed development environment. Peck specifically highlights developer experience gains from using it for boring activities, such as building unit tests for new code or auto-summarizing the functionality of components.

Running Automation in the Background

Having more automation baked in is another way GitHub enhances its developer productivity and experience. “Developer-facing automation allows devs to stay in the flow longer, interrupting them only when something needs their attention,” said Peck.

For example, teams utilize GitHub Actions for all kinds of triggers, such as responses to new code commits or changing the state of issues, said Peck. Running asynchronous tests in the background and notifying the developer only if something breaks enables them to stay head-down in the code for more extended periods. Additionally, asynchronous communication around pull requests and code reviews can ensure teammates collaborate effectively on their own time.

These traits are often adopted in cloud-native software development cultures like GitHub. The more you can make tests and build processes run in the background, the better, explained Kalliamvakou. Plus, reducing notification fatigue is another way to ensure developers aren’t interrupted unless something really needs their attention.

Regularly Collecting Feedback

To optimize developer experience, it’s a good idea to collect developer feedback. For instance, at GitHub, their developer experience team regularly conducts internal surveys to surface areas for improvement — this helps gauge satisfaction with the amount of deep work developers are engaged in. Similarly, LinkedIn regularly collects qualitative input using an internal framework to gauge developers’ satisfaction with their tools.

GitHub also runs a newsletter to spread awareness about what new internal features they’re introducing and to regularly review the state of things. “When you introduce a developer experience initiative, you need to create awareness around it and track how people are responding over time,” said Kalliamvakou. Keeping an active tab on the success of these initiatives is a good health check to avoid burnout.

Shifting Security Left A Bit

Another area where GitHub focuses on improving developer experience is around security. Traditionally, systems perform security scanning after all code is committed. However, this can be a big pain to go back and fix, especially when you need to track down multiple dependencies and don’t have great visibility.

“The closer you get security scanning to the point where the vulnerability was created, the easier it will be to remediate it,” said Peck. Shifting left to detect potential vulnerabilities in the moment and offering “one-click to remediate” options can significantly enhance the developer experience. He also described how GitHub engineers dogfood GitHub’s advanced security features to perform things like ongoing secrets scanning, input sanitization and pattern-based analysis.

Making Processes Understandable and Intuitive

Interestingly, the DevEx in Action study found that developers who report a high degree of understanding of their code feel 42% more productive than those with low or no understanding. So then, how can we enhance our understanding of code?

Often, a developer might forget the context behind something they wrote last year, or something a teammate programmed might seem obfuscated. This is another area where AI could be utilized to generate documentation automatically. However, the future of code understandability goes beyond just static documentation.

“The trend is toward learnability right where they are, to keep them in the flow,” said Kalliamvakou. She indicates that AI-driven insights embedded into the IDE that explain what a program or function means make the developer workflow highly intuitive.

Offering Cloud-Based IDEs

Developers often run into the “works on my machine” problem, which can be a big developer experience hurdle. In essence, applications depend on far more than just the code — they are at the whim of the environment, local dependencies, its configurations, and the actual device running the program.

By using cloud-based IDE like Codespaces, said Peck, GitHub developers are able to spin up a container in the cloud and retain the same configurations. The benefit of this is that you can keep your local editing experience as well, he said.

Retaining An Engaged Developer Experience

According to Kalliamvakou, the benefits of developer experience are no longer just anecdotal — we now have real-world evidence to back up these claims. For instance, developers who find their work engaging feel 30% more productive, according to the aforementioned report.

It seems that having an AI coding assistant by your side trained on a large language model (LLM) can encourage developer satisfaction and productivity gains. Introducing AI-based tooling can help automate away some of the unfulfilling work, leaving more time for more engaging activities, said Kalliamvakou.

But although AI can solve many things, there will always be some degree of toil. Kalliamvakou recommends distributing grunt work across multiple employees and avoiding throwing it all on one person! At GitHub, the DevEx team also analyzes the efficiency of meetings to remove non-high-quality meetings, which can also benefit engagement.

February 8, 2024
Kobiton Open Sources Test Script Generation Tool

Kobiton today announced it is open sourcing a script generation tool for the Appium automation framework that automates the running of test scripts.

The overall goal is to make the tool, which makes it simpler to create more testing scripts, more widely available and, ultimately, lead to higher-quality applications being deployed.

Kobiton CTO Frank Moyer said the tool makes it possible to generate tests from a test case that has been captured in a Node.js format. Rather than having to hire hundreds of testers to create those scripts manually, it’s now possible to automate those tasks using an open source tool, he added.

On average, Kobiton claims the tool it developed can write a 30-step script in 10 minutes, whereas a manual approach could take as long as four hours to construct a similar test.

Once created, those test scripts can automatically be executed using the Appium framework. The output from that tool can also be used on other testing platforms, including Sauce Labs, BrowserStack and LambdaTest or integrated with low-code testing platforms from Perfecto and Tricentis.

It’s no secret that the quality of any given application tends to vary widely, not just between organizations but also within them. Most of those issues can be traced back to a lack of testing that usually occurs because there isn’t enough time. As deadlines near, one of the first places organizations look to make up for delays is the time available for testing. The hope is that whatever issues arise will be addressed via the next update. Of course, when the update falls behind schedule, the testing process is again cut back.

Ideally, application development projects would not be allowed to go forward without adequate testing, but given business pressures, they often do. The only way to limit the impact of application development delays is to reduce the time required to create and run tests. The more automated that process becomes, the less time there will be spent on manually running routine tests. In fact, hopefully, there might even be enough time to run more complex tests to uncover issues that might adversely impact the user experience in ways no one might have otherwise considered.

One way or another, the quality of the applications being deployed needs to improve if for no other reason than end users have options. Most end users will never give a mobile application a second chance if the initial experience doesn’t meet expectations. At the same time, application security regulations are only going to become more stringent. The tolerance for known vulnerabilities discovered after an application has been deployed is falling. Many organizations will find themselves subject to fines being levied simply because there was not enough adequate testing baked into the software supply chain.

In fact, application security should, in the final analysis, be an element of a large quality assurance process that begins with adequate testing.

February 8, 2024
Survey Surfaces Raft of Ongoing Agile Development Challenges

A survey of 788 software development professionals finds 71% are using agile development methodologies within their software development life cycle (SDLC) but only 44% said it is working very well (11%) or somewhat well (33%) in the enterprise.

Conducted by Digital.ai, the survey identifies end-to-end visibility and traceability from business initiative through deployment as the top opportunity for improvement (44%), followed by an ability to measure cycle time, wait time and bottlenecks (34%), continuous testing (29%) and identification and measurement of technological risk (28%).

Nearly half (46%) identified too many systems as a primary reason Agile was not scaling, followed by siloed teams (37%), culture clash (34%), inconsistent adoption (30%) and the inability to measure business value (28%).

Despite these issues, nearly two-thirds (63%) said they have visibility into their Agile pipeline, with 55% claiming they have complete visibility. However, only 36% said DevOps teams currently work together as one team to accelerate innovation and deployment of high-quality and more reliable software. At the same time, only two-thirds (66%) claimed at least 50% of their applications were delivered on time and “with quality.”

Joyce Tompsett, general manager of the State of Agile project at Digital.ai, said the survey makes it clear many organizations are still trying to strike the right balance when it comes to developing software. For example, the survey finds the top two reasons organizations adopt Agile (tied at 41%) are to accelerate time to market and prioritize delivery and measure customer/business value. Most software development teams are being evaluated both based on velocity (33%) and the value delivered (29%), the survey finds.

The survey also identifies customer satisfaction (43%), time to delivery (39%) and competitive advantage (34%) as their top priorities for 2024.

In general, the survey finds that 33% of respondents reported business leaders and executives are actively leading and participating in company-wide agile transformation. However, more (41%) said there was not enough leadership participation. Well over a third (37%) said business teams simply don’t understand what Agile is or what it can do. More than a quarter (27%) said there is not enough training.

Not surprisingly, the most widely adopted methodology is Scrum (63%) with the Scaled Agile Framework (SAFe) being the most widely used (26%). Another 22% don’t have a mandated framework, while 12% said they have created their own.

The debate over what precisely constitutes agile development is, of course, ongoing. Each organization tends to adopt the elements of the framework that make the most sense for them, so the actual state of adoption from one organization to the next will vary widely. The one thing that is certain is the more complex the IT environment, the more challenging it can be to embrace agile development.

And there continues to be lots of room for improvement. If only two-thirds of organizations are delivering half (50%) of their applications on time with an acceptable level of quality, it means there are more projects that are failing to meet that standard than many software development teams might care to admit.

As more organizations become more dependent on software, however, tolerance for that level of failure will only continue to decline as businesses and leaders lose patience with application development practices that do not live up to expectations.

February 7, 2024
OpenText Extends Tool for Auditing Source Code Using Machine Learning

OpenText this week updated a static analysis tool it provides to audit code using machine learning algorithms to provide deeper insights into on-premises IT environments.

Announced at the OpenText Security Summit 2024 conference, the latest generation of Fortify Audit provides additional artificial intelligence (AI) models capable of learning the unique attributes of custom source code.

The latest version of Fortify Audit Assistant also adds the ability to detect drift in a model and, if necessary, automatically refresh it. OpenText is now committing to refreshing those models every quarter.

The discriminant AI model from OpenText enables machine learning algorithms to learn how humans conducted an application audit to then run similar tests on other applications. Previously, Fortify Audit relied on the same core model to audit both on-premises and software-as-a-service (SaaS) applications based on data collected by OpenText. Fortify Audit Assistant now provides support for more than 30 language-specific models to improve testing performance.

Dylan Thomas, senior director for Fortify engineering and product for OpenText Cybersecurity, said this capability ensures that any sensitive data never leaves an on-premises IT environment.

The overall goal is to streamline the number of alerts that would otherwise overwhelm a DevSecOps team trying to identify the root cause of an issue, he added. For example, Fortify Audit Assistant will identify test code that is not vulnerable because it was never deployed in an actual production environment. That approach makes it easier for DevOps teams to prioritize which vulnerabilities to fix first in their source code using a lightweight AI model that still enables them to deeply scan source code, noted Thomas.

Historically, DevSecOps teams need to make a trade-off between lightweight approaches and deep scans of source code that is no longer required, he added.

As regulations pertaining to software supply chain security become more stringent the number of development teams that will be subject to some type of audit is only going to increase. The cost of failing an audit will also inevitably increase as regulatory bodies look to make examples of organizations that are not properly securing their software supply chains.

It’s not clear how aggressively organizations are embracing best DevSecOps practices to address myriad software supply chain security issues that were highlighted in an executive order issued by the Biden administration to Federal agencies. However, with the rise of AI and other forms of automation, it should become simpler to identify more vulnerabilities before they wind up being exploited in a production environment.

There will always, of course, be a need to secure production environments because there’s always a probability mistakes will be made. However, given the lax practices many organizations have employed to build and deploy applications, it’s probable the number of vulnerabilities that exist in production environments today is beyond counting. In many cases, the better part of valor might be to replace many of those applications entirely with ones built using DevSecOps best practices.

Regardless of the path to better application security chose the one thing that is certain is cybercriminals are only going to become even more adept at discovering those vulnerabilities.

February 6, 2024