Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.
This week: Red Hat Enterprise Linux (RHEL) goes closed source. Well—no, not really; but IBM’s lawyers are accused of skating so close to the edge of legality that they risk violating the GNU Public License. (more…)
HashiCorp this week revealed it has acquired BluBracket to add a set of scanning tools for discovering static secrets to its portfolio.
James Bayer, senior vice president of research and development for the Secure product line at HashiCorp, said the existing Vault platform for managing secrets is designed to enable developers to manage them as they build applications. BluBracket has developed a secrets management tool that makes it possible to discover secrets in applications that have already been deployed in production environments, he said.
The amount of secrets management-related technical debt many organizations have can be enormous, especially if they’ve been deploying applications for decades. IT teams need a tool that discovers secrets in applications that, in many cases, were deployed by application developers that are no longer with the company, Bayer added.
The BluBracket tools make it possible to discover those unmanaged secrets even before efforts are put in place to improve application security, he noted.
HashiCorp will initially integrate BluBracket’s functionality into HashiCorp Vault to expand HashiCorp’s zero-trust capabilities, and add detection and remediation workflows via additional capabilities expected later this year. That’s critical, because for decades, developers have been storing secrets in applications and forgetting to remove them before an application is deployed.
In general, HashiCorp is moving to transform its Vault platform into an orchestration engine for managing secrets regardless of where those secrets might be stored, said Bayer. That approach will enable developers to build applications and store their secrets on, for example, the Amazon Web Services (AWS) cloud in a way that can be centrally managed via the Vault platform, he added.
Most organizations today are at varying stages of embracing DevSecOps best practices to improve software supply chain security. It’s not clear how readily secrets management is being embraced as part of those modernization efforts, but as cybercriminals routinely scan for application secrets stored in clear text, the need to encrypt secrets becomes a higher priority.
The core DevSecOps issue most organizations are wrestling with is how involved cybersecurity teams should be in application development. There’s clearly a concerted effort to push more responsibility for application security further left toward developers. The challenge is, even when those tools are provided, it’s not clear that developers can distinguish between the severity of one vulnerability versus another.
Conversely, most cybersecurity teams don’t really understand how modern applications are developed. That doesn’t necessary mean cybersecurity professionals need to dive deep into application development workflows, but it does mean they should, at the very least, understand how applications are constructed to make sure the appropriate security guardrails have been put in place.
Regardless of approach, it’s clear there is a need for some type of centralized security function to better ensure application security. Unfortunately, the cultural divide between application developers and cybersecurity teams remains fairly wide. The DevSecOps journey ahead will be long, as each organization determines how best to bridge that gap when the supply of available cybersecurity expertise remains constrained.
A survey of enterprise IT leaders found less than a third (32%) are extremely confident that they have the right technology, processes and people in place to execute an effective approach to IT management.
The survey, conducted by Rocket Software, polled 275 U.S. IT leaders in organizations with more than 1,000 employees. A full 93% of IT leaders are also committed to maximize the value of investments in existing platforms.
As a result, the top priorities for IT leaders are hybrid cloud computing (65%), data and content management (68%) followed by DevOps and infrastructure and application modernization, tied at 58%, and automation (57%).
A total of 62% noted they have a much greater focus on efficiency due to the economic landscape, with faster DevOps processes, automated processes and increasing overall output as the top three improvements that would be most impactful for increasing efficiency.
The survey also suggested many organizations still have much work to do to achieve those goals, with 63% of respondents spending anywhere from six to 15 hours on manual data entry and analysis each week.
Phil Buckellew, president of infrastructure modernization for Rocket Software, said most organizations are still trying to determine the right level of DevOps to adopt. Few organizations have implemented DevOps workflows on an end-to-end basis, with many employing a mix of DevOps and waterfall processes to build and deploy applications across a hybrid cloud computing environment, he noted.
Overall, IT leaders are most worried about improving overall IT performance (60%), data security (50%), process risk and compliance (46%) and the need to improve agility (41%), the survey found. Respondents also noted that they measure success within their IT organization by increased efficiency (71%), optimized resources (67%) and reduced risk (63%).
The survey makes it clear that, despite challenges, enterprise IT organizations are committed to hybrid cloud computing as they become more comfortable with using various platforms that are fit for purpose, said Buckellew.
Mainframes, for example, continue to play a major role in running online transaction processing (OLTP) applications alongside analytics applications that are now being infused with artificial intelligence (AI) capabililities, noted Buckellew.
A quarter of survey respondents also identified providing cloud applications with access to mainframe data as an area where they need additional tools, followed by automation (22%).
The biggest automation obstacles are the complexity of implementing automation (18%), resistance to process change among workforce (18%) and lack of skillsets to implement automation (18%), the survey finds.
As always, the biggest challenge in enterprise IT environments is often simple inertia. Organizations that have been building and deploying applications on mainframes, for example, have been relying on waterfall processes for decades. Many of them have now adopted DevOps processes to varying degrees, but few have completely replaced legacy approaches to building and deploying software, noted Buckellew.
It’s not likely the management of complex hybrid cloud computing environments will be simplified any time soon, but progress continues to be made. Soon, AI may automate many existing manual tasks. In the meantime, however, the number of enterprise IT organizations standardizing on a single IT platform remains few and far between.
Bionic this week added a pair of tools to its application security posture management (ASPM) platform that make it simpler to triage threats based on severity and attach a risk score.
Josh Cho, senior director of global systems engineering at Bionic, said the Bionic Signals and Business Risk Scoring tools ingest data from third-party security tools to provide analytics capabilities. The first two vendors with which Bionic has integrated its ASPM platform are Wiz and Sonatype.
The goal is to partner with additional vendors that provide unique cybersecurity capabilities that don’t compete with one another, said Cho.
The agentless Bionic ASPM platform enables organizations to manage application risks by continuously collecting data from services and their dependencies, application programming interfaces (APIs) and DevOps data flows both in pre-production environments and after applications are deployed. Bionic then assesses any changes made to those environments based on a set of cybersecurity policies it provides. If an issue is discovered, the platform will create an alert informing the appropriate development team of best practices that eliminate the issue.
While there is a lot of effort being made to shift more responsibility left toward application developers, there is often not enough cybersecurity context provided, said Cho. Bionic’s ASPM platform aggregates data from multiple tools to enable DevSecOps teams to better prioritize their remediation efforts, he added.
It’s not clear how much organizations have embraced DevSecOps best practices, but one of the issues that needs to be addressed is the often-conflicting alerts generated by the various tools being used. Bionic is making a case for an ASPM platform that synthesizes data from multiple sources to streamline DevSecOps workflows.
One way or another, more organizations will be embracing DevSecOps to better secure their software supply chains as more regulations are mandated. The challenge they face today is that most application developers—and the DevOps teams that support them—don’t have a lot of cybersecurity expertise. As a result, it becomes difficult to discern which vulnerabilities require immediate attention and which can be addressed in a regular update. In some instances, an alert generated by a cybersecurity team may not even been relevant—because the application in question is not internet-facing or the impacted module has not been loaded.
In fact, it’s that very lack of context that often results in application developers disregarding the alerts generated by cybersecurity teams. Whenever there is a breach, however, cybersecurity teams always demand to know why their alert was ignored.
No developer, of course, deliberately sets out to build and deploy vulnerable applications. In the race to meet delivery deadlines, there are always going to be tradeoffs. The issue then becomes keeping track of the cybersecurity technical debt that accumulates over time. An ASPM solution provides a means to keep track of that debt to enable DevSecOps teams to keep the risk in perspective.
Platform engineering is emerging as method for managing DevOps at scale, but a survey suggested that many organizations are still not clear on the concept.
A survey of 100 DevOps engineers, platform engineers, developers, site reliability engineers and IT managers conducted by Civo, a cloud service provider, found 85% of respondents work for organizations that have partially or fully embraced a DevOps culture, with nearly two-thirds (65%) identifying platform engineering as the next evolution of DevOps. Nearly, a third (30%) of respondents work for organizations that are already currently evaluating whether they should adopt platform engineering.
Overall, the survey found 50% of the respondents at organizations that have adopted platform engineering reported improved standardization, with 43% also seeing faster product delivery.
However, only 41% of the respondents in DevOps roles that were familiar with platform engineering said they had a moderate to high level of familiarity with the concept.
Saiyam Pathak, director of technical evangelism at Civo, said the survey makes it clear that, in terms of understanding how platform engineering best practices should be implemented, there is need for more clarity. Many organizations initially adopted DevOps to spur innovation, so any approach to centralization shouldn’t come at the expense of developer productivity, he noted.
Historically, DevOps adoption of DevOps workflows in most organizations has been driven from the bottom up. As a result, it’s fairly common for multiple application development teams within an organization to have adopted multiple DevOps platforms to manage workflows. Advocates for platform engineering are making a case for eliminating many of those redundant platforms in favor of, for example, a single continuous integration/continuous delivery (CI/CD) platform that serves as a corporate standard.
At the core of those efforts is the assumption that centralization will reduce costs by eliminating redundancy. At a time when more organizations than ever are sensitive to the cost of IT, there is always going to be a natural tendency to rationalize platforms. Challenges arise, however, when centralization results in a loss of flexibility. Many of the teams adopt DevOps because they want to be able to add and replace tools as they see fit. If there is a corporate standard that narrows their tool options, those teams may start to look for ways to do an end-run around the corporate standard.
The philosophical IT battle between advocates for centralization and proponents of decentralization has been around since the first PCs showed up in enterprise IT environments. As always, organizations need to strike a balance between both extremes, said Pathak.
It’s not clear how much platform engineering might accelerate the pace at which applications are built and deployed, but the total cost of DevOps should decline as various tools and platforms are consolidated. The challenge, of course, is that centralizing DevOps workflows is likely to disrupt the application development workflows on platforms that may about to be rationalized.
Regardless of what platforms become the corporate standard, the one thing that is certain is the cultural challenges associated with successfully making that transition will loom large within most organizations.
Mendix, a subsidiary of Siemens, today updated its namesake low-code application development platform to add support for DevOps workflows and make it simpler for developers to compose applications and embed artificial intelligence (AI) capabilities.
Sheryl Koenigsberg, vice president of product marketing for Mendix, said Mendix 10 makes it possible to use Git repositories for version control along with Mendix Pipelines, currently in beta. Mendix Pipelines is a continuous integration/continuous delivery (CI/CD) environment that will be embedded in the low-code platform. In addition, Mendix is adding support for Webhooks that can be used to integrate Mendix with existing CI/CD platforms.
Mendix has also added a Solutions Kit, now generally available, to make it possible to customize applications in a way that ensures those changes will be preserved as application environments are upgraded.
There is also now a Portfolio Manager tool to track projects and a connector for integration with the Jira project management software from Atlassian.
Later this year, Mendix will also make generally available Adaptation Insights to provide insights into application extensions.
In the future, developers will be able to leverage an extensibility framework to tailor the Mendix Studio Pro integrated development environment (IDE) by adding their own plugins, wizards, editors and third-party integrations. Later this year, Mendix 10 will also add, in beta, a version of its Studio Pro IDE for MacOS.
The Mendix approach to composability is also being extended to incorporate AI. The company is adding Mendix Assist, a bot that generates validation logic for data entry. This module is the second AI capability that Mendix has developed after previously previewing Mendix Chat, a tool based on a large language model created using Mendix data that will be integrated into the Mendix integrated development environment (IDE) later this year. Mendix Assist will be incorporated into Mendix Chat.
Mendix is also developing additional LLMs for creating applications and will as part of its commitment to composability plans to make it possible to integrate third-party AI services and LLMs into the Mendix Runtime to create “smart apps.” AI models will be converted to the Open Neural Network Exchange (ONNX) format, an open standard for machine learning models, to provide that capability.
In addition, Mendix is adding support for event-driven architectures via Business Events and an Event Broker, to build more complex applications.
Other capabilities being added to Mendix 10 include updated REST and database connectors, support for visual data filters, rich properties and design controls, a Start from Spreadsheet tool, end user survey tools, a PDF document generator and a revamped set of governance and risk assessment tools.
Finally, Mendix is adding a Terraform module to make it simpler to deploy its low-code platform on the Amazon Elastic Kubernetes Service (Amazon EKS) in addition to providing a reference implementation for building private clouds to develop applications using the Mendix Cloud service.
As AI-infused low-code applications are developed faster, it’s not clear to what degree organizations are prepared to embrace the inevitable disruption that will ensue. However, the one thing that is clear is that the DevOps workflows used to deploy these applications at scale will soon be put to the ultimate test.
OutSystems, via a Project Morpheus initiative, intends to leverage generative artificial intelligence (AI) technologies to make it possible to automatically generate an application that developers will then use low-code tools to customize for specific use cases.
In the meantime, the company is extending an existing alliance with Microsoft to provide a connector that integrates its namesake low-code platform with instances of ChatGPT. These instances are made available via Microsoft’s Azure OpenAI cloud service to make it possible to build a low-code application in a matter of minutes.
Rodrigo Coutinho, director of data science for OutSystems, said that as generative AI continues to evolve, it will become possible for developers to use a natural language interface to create an application. However, there will also be plenty of instances where end users still prefer to access applications via a graphical user interface that developers build using low-code platforms, he noted.
An application editor will also provide ongoing suggestions for everything from how the user interface is designed to the way data is managed.
Developers will also be able to verify how code functions using the OutSystems visual language. In addition, The OutSystem compiler will be able to deterministically detect threats and code patterns produced by generative AI platforms that will include Google, Amazon and others alongside Microsoft.
Ultimately, citizen and junior developers will be able to build sophisticated applications that previously would have required the skills of a professional developer, noted Coutinho.
It’s not clear how much developers will embrace a low-code platform to build software. However, the one thing that is certain is the whole process of defining requirements before an application can be built will soon become obsolete as the building of an application becomes more iterative and involves developers working alongside subject matter experts, added Coutinho.
It may awhile before that vision of application development is realized, but the pace at which applications are built and deployed is clearly about to accelerate. The impact of all that code will naturally vary, but it’s already apparent that the cost of building many applications may soon drop to almost zero. Developers will soon be spending more time on making sure workflows are logical than writing actual code, noted Coutinho.
In addition to relying more on AI to build software, organizations should also rely more on AI to deploy it at unprecedented levels of scale. The days when application development projects were measured in months, sometimes years, is coming to an end. AI platforms will enable organizations to experiment at will because the time and effort required to build and deploy a new iteration of an application will be virtually nil.
Of course, no one can predict what impact all that code will have on society as we know it. But the only limit going forward may soon be what our collective imaginations can conceive than the level of developer expertise that can be marshalled at any given time.
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:
Indeed.com
PEAR Health Labs
Remote
DevOps Manager
$150,000 to $175,000
Dice.com
SR Partners
Dallas, Texas
DevOps Architect
$140,000 to $160,000
SimplyHired
Reynolds & Reynolds
Tallahassee, Florida
Senior Software Architect
$106,000 to $135,000
Genesys
Oakdale, Connecticut
Senior Software Engineer: DevOps
$93,600 to $194,400
CareerBuilder.com
Patterned Learning AI
Remote
DevOps Engineer
$60,000 to $70,000
Integral this week launched an open source Robin AI project that leverages OpenAI’s generative pre-trained transformer (GPT) platform to review code changes and provide constructive feedback.
Integral is a data analytics platform used by health care providers. The company originally developed Robin AI using a set of Bash scripts to create a generative artificial intelligence (AI) tool to assist its internal development team.
Integral CTO John Kuhn said Robin AI is essentially a bot that functions like a coach for developers. It first reviews code and then surfaces optimization suggestions that developers can instantly apply, said Kuhn. It’s up to each developer to decide whether to accept those suggestions, but Integral is already using it to, for example, make sure all the code being written is human readable, he added.
Robin AI currently works best on JavaScript code repositories, but can be applied to any codebase residing in a Git repository. Integral has also already developed a GitHub Actions script.
In addition, as an open source project, Robin AI can be integrated with any number of generative AI platforms that might be built using more domain-specific large language models (LLMs), noted Kuhn.
Most developers are already using AI tools such as GitHub Copilot to write better code. Robin AI is now extending generative AI capabilities to the code review process as part of an effort to improve the quality of the code being written. In effect, it provides a means to surface common mistakes developers make and enables them to fix those before they are discovered by a colleague.
It’s not clear how much application development will be driven by AI, but Kuhn said he believes it’s only a matter time before the entire software engineering process is automated. As those advances are made, the cost of building applications will effectively drop to zero, he added.
Of course, not everyone in the application development community agrees with that assessment. But one thing that is clear is that generative AI capabilities will soon be pervasive. In fact, the next frontier will arguably involve integrating generative AI platforms with frameworks that make it possible to automatically apply suggestions and recommendations made by generative AI platforms across an entire enterprise IT environment.
In the meantime, DevOps teams should be evaluating generative AI technologies in terms of the capabilities they can provide today and their future potential. Many of the manual tasks that conspire to make application development and deployment tedious will become increasingly automated. DevOps teams committed to ruthlessly automating as many processes as possible will naturally be at the forefront of adoption. The challenge and the opportunity lies in determining whether AI platforms can be trusted or if a human must always be in the loop to ensure there are no unexpected outcomes.
After all, while AI can be applied to automate deployments, it’s not quite as clear whether they can be rolled back if a mistake is made.
Organizations are still increasing their use of low-code/no-code (LCNC). But this adoption isn’t always consolidated around one tool—frequently, multiple low-code/no-code platforms are used under the same roof. In fact, Gartner predicts that by 2024, 75% of large enterprises will be using at least four low-code development tools for both IT application development and citizen development initiatives.
Utilizing multiple low-code/no-code platforms simultaneously introduces some security concerns. This is partially due to a lack of standard policies to govern different platforms in the same way. Low-code platforms are often incompatible with traditional IT security processes, like vulnerability scanning, manual code reviews and runtime security monitoring. Organizations going all-in on citizen development need safe ways to use low-code/no-code platforms. So, how can they safely enable this innovation without hindering productivity?
I recently met with Michael Bargury, CTO and co-founder, Zenity, about securing LCNC systems. Bargury, who oversees the OWASP Low-Code Top Ten list, has significant insight into both the benefits and drawbacks of low-code/no-code platforms. Below, we’ll review the potential risks of using multiple low-code platforms and consider ways to mitigate these concerns.
Interest in low-code has been rising, and low-code/no-code adoption continues to accelerate across enterprises. According to Bargury, large enterprises often don’t get a choice in the matter—low-code tools are arising organically, and it’s challenging to keep a lid on their proliferation.
One way this occurs is that low-code becomes embedded into the SaaS platforms everyone already uses. Software platforms integral to business operations, like Salesforce, Microsoft Office and ServiceNow, have arguably mutated into low-code platforms, making them more like cloud providers than SaaS vendors, said Bargury.
The other way low-code platforms emerge is through bottom-up transitions, says Bargury. This could be a specific knowledge worker working in a subset of the business to automate a domain-specific operation or integrate various tools. Then, there are the platforms, like OutSystems, Mendix or Mulesoft that specifically target professional developers.
Organizations going all-in on citizen development may build a center of excellence and focus efforts on a single platform. And low-code platforms targeting developers will sometimes encourage more consolidation. Yet, “different platforms solve different use cases better,” explained Bargury. As a result, you will usually have a few converging in the same enterprises.
The emergence of low-code is similar to the bring your own device (BYOD) movement. IT and security leaders fought to avoid it at one point, but nowadays, everyone does it. So, what are the security implications if low-code becomes similarly ubiquitous? Well, no matter how it’s generated, low-code-bred programs are still applications susceptible to the same logical problems. And unfortunately, compared to your typical traditional code development life cycle, low-code development is fraught with discrepancies, says Bargury.
Some platforms do not offer the kind of mature CI/CD process one would expect from a software development platform. For example, there may be no way to create tests or separate your environments. Since there’s no coherent and consistent way to push code from development into production, you lack a way to apply secure development across platforms. “You don’t have a way to ensure every piece of software is up to your standards,” said Bargury.
In traditional software development, you apply your own security reviews to ensure applications don’t contain risks. This includes shift-left scanning, security gates, manual reviews to catch mistakes early on and runtime scanning to catch unknown vulnerabilities in production. But there aren’t always parallels in low-code development. Low-code solutions typically have their own way of doing things with fewer standards, and they avoid exposing the underlying code and Git, said Bargury.
As such, with low-code obfuscation, you lose a degree of visibility into how an application runs. Logs may be insufficient or wholly inaccessible. It’s also tricky—or at times impossible—to set up runtime monitoring, let alone scan various platforms. This means that low-code users can’t leverage powerful observability tools to identify errors and remediate security holes.
Finally, establishing common authorization and permissions across multiple low-code development platforms is another hurdle. Since low-code vendors have their proprietary building blocks, you’re unable to leverage something like OPA or Kyverno to create and unify policies. Lacking shared policies across tools makes it challenging to verify that best practices have been implemented, says Bargury.
Low-code can grant much creative potential. But, knowing the above risks, what should IT be doing to reduce risks around low-code—especially when using multiple platforms? Well, Bargury shared several steps to help cybersecurity leaders start safely addressing the emergence of increasingly low-code capabilities.
Low-code development platforms aren’t 100% safe from harm. It’s not out of the question for hackers to abuse low-code platforms and turn them against their owners. For example, Microsoft’s Detection and Response Team (DART) reported how a hacker group used entry to a low-code tool to remain hidden within an organization for six months, using credential stuffing to access an administrative account. By creating automations, they were able to use internal discovery tools and exfiltrate secrets and data that could have been used for privilege escalation.
As you can see, there are legitimate concerns for low-code, especially at scale. However, security responsibility is not always that transparent. To date, there isn’t an equivalent of a shared cloud responsibility model in the realm of low-code development. As such, at the end of the day, you need to take the reins to own the applications that you build and ensure everything is secure.