devopsy.kinsta.cloud

Category: Continuous Testing

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate.

  • Dynatrace Extends Data Reach and Scope of Observability Platform

    Dynatrace Extends Data Reach and Scope of Observability Platform

    At its Perform 2024 event today, Dynatrace unfurled a Dynatrace OpenPipeline that makes it possible to apply analytics to multiple types of data sources in real time.

    The company also unveiled a Data Observability offering that can be used to vet the quality and lineage of data being exposed to the Davis artificial intelligence (AI) engine at the core of the Dynatrace observability platform to reduce false positives that otherwise might generate an alert in addition to helping reduce the volume of data that might need to be stored.

    Finally, Dynatrace announced it is starting today extending the reach of its observability platform to the large language models (LLMs) that are used to create generative AI platforms. That capability will, for example, make it simpler to monitor the consumption of tokens that are used to provide access to these models.

    Steve Tack, senior vice president for product for Dynatrace, said Dynatrace OpenPipeline will enable organizations to streamline the collection of data in a way that will enable them to apply observability more broadly by applying stream processing algorithms to petabytes of data.

    Scheduled to be available in 90 days, the Dynatrace OpenPipeline capability enables IT teams to ingest and route observability, security, and business events data from any source and in any format at the point of ingestion, including unstructured data that is automatically converted into a usable format. That data can then be enriched to enable deeper analytics.

    It also provides IT teams with more control over which data they analyze, store or exclude from analytics, which in turn helps reduce the total cost of observability, noted Tack.

    Finally, it presents IT teams with the ability to apply more customizable security and privacy controls to how that data is employed, he added.

    Dynatrace is pursuing a multimodal approach to AI that spans predictive, causal and generative models. Collectively, that approach makes it simpler to identify the root cause of issues, identify anomalies that might disrupt services and streamline incident management by, for example, providing summarizations of events in a natural language format.

    It’s not clear how broadly observability will be applied beyond the data collected to manage DevOps workflows and other IT processes, but it’s clear there is a high correlation between IT events and business outcomes as organizations become more dependent on software. As AI becomes more pervasively employed, it should become simpler to apply analytics to a much wider range of types of data to surface the relationship between IT events and business processes. In effect, Dynatrace is making it simpler to apply best data engineering practices to collect, manage and analyze that data, noted Tack.

    In the meantime, DevOps teams should revisit how their pipelines are currently constructed to make it simpler to capture all relevant data. As critical as telemetry data collected from the DevOps platform is to ensure application development and delivery occurs as fast as possible, that data is only one factor in a larger equation. The challenge and the opportunity now is determining how best to apply AI to correlate it all.

  • How to Make the Most of In-House Software Development

    How to Make the Most of In-House Software Development

    Let’s be blunt: Maintaining an in-house software development team can be tough. You must hire skilled developers – which is no easy feat in today’s economy, where talented programmers remain in short supply – and then manage them on an ongoing basis. You must also ensure that your development team is nimble enough to respond to changing business needs and that it can adapt as your technology stack evolves. Given these challenges, it’s no surprise that most organizations now outsource application development instead of relying on in-house teams.

    But I’m here to tell you that just because in-house development can be hard doesn’t mean that outsourcing is always the best approach. On the contrary, IT organizations that choose to invest in in-house development for some or all the work can realize lower overall costs and a competitive advantage by creating domain-specific expertise. Keeping development in-house can help organizations address unique security requirements and maintain full control over the development lifecycle and roadmaps. For businesses with specialized technology, security and operational needs, in-house development is often the best strategy.

    Managing an in-house development team presents some steep challenges. At Komprise, we have refined several practices to keep our team efficient and productive, even in a business environment that is constantly changing.

    Scaling Up

    Scaling teams up is a key challenge for in-house development teams. Finding skilled developers to grow a team can be very difficult, especially when working with a bespoke technology stack.

    There is no simple solution to this challenge, but there are steps you can take to maximize your ability to find and hire development talent. For example, we invest significantly in engaging with college students, allowing us to identify promising developers while they are still in training.

    At the same time, we invest in upskilling our developers who are already on our team so they can take on additional responsibilities. We train our engineers in the latest cloud development and security skills and knowledge. The notion of embedding security into our designs and practices is fundamental to what we do. We also rotate engineers between different teams so they learn new technologies that are important to our business. This strategy allows us to align the work for every developer with their interests and to build reusable skills within our teams. We also hold a technical brown bag three times per month where we cover issues like development for cloud and how it differs from on-premises due to costs or how to design for performance and scalability.

    Focus on Customer Value

    Figuring out which features customers want most is a constant challenge. To address it, we quantitatively track how our customers use our product – which functionality they use most often, for example, and how usage patterns vary across different customer demographics. We evolve these metrics as we develop the product. Additionally, we identify customers who are “power users” and occasionally set up calls between them and our developers to gain additional insight into what customers want. Our marketing team also conducts customer advocacy interviews with our users to learn more about what they like and don’t like.

    Looking at third-party applications and interfaces helps us gain perspective on how best to meet user needs, too. For example, we might examine how Wayfair or Amazon are evolving their UI constructs to inform how we could change our product interface in ways that better meet customer needs. We want our B2B product to be as easy to use as consumer products.

    Invest in QA

    Quality Assurance (QA) operations are distinct from development operations, but if you want a successful in-house development team, you need a great QA team, too. Our QA engineers complement our in-house developers by helping them to deliver the highest-quality product, while also strategizing over how best to handle scale and efficiency challenges. In addition, we’ve invested heavily in QA automation, allowing us to test our applications thoroughly while keeping our team lean and efficient. This ensures that as our product feature set expands, our ability to test the entire product does not increase and we can maintain a monthly release cadence. We use test harnesses to simulate error and failure conditions, by injecting failures into the system or making our network experience a brownout or a blackout. You can’t automate every software test, but you can automate most of them, and QA automation is one of the key ingredients in effective development operations.

    Leverage AI Strategically

    AI is not the solution to every development challenge, but when used properly, AI can accelerate development and help in-house developers work more efficiently. Using AI tools to churn out code has become a hot use case for AI in development since the introduction of solutions like Copilot. AI can be a very useful solution, but the quality of the results it delivers hinges on the quality of the data it ingests. Inhouse development teams working on AI applications have much to consider from the data perspective. To leverage unstructured data, they need ways to find it across data silos, enrich it with new metadata as needed to support search and leverage AI tools like Amazon Macie and Rekognition to further refine the data.

    Optimizing In-House Development for the Long Term

    The importance of keeping in-house development teams happy and productive is likely only to increase as the tasks they work on grow more complex and as new paradigms, like those driven by AI, change the way developers work. The more IT organizations and enterprises can upskill their existing developers and empower them with the right tools and processes to succeed, the better they can leverage their teams to build products and features that bring value to the business.

  • SmartBear Acquires Reflect to Gain Generative AI-Based Testing Tool

    SmartBear Acquires Reflect to Gain Generative AI-Based Testing Tool

    SmartBear this week revealed it has acquired Reflect, a provider of a no-code testing platform for web applications that leverages generative artificial intelligence to create and execute tests.

    Madhup Mishra, senior vice president of product marketing at SmartBear, said the platform Reflect created will initially be incorporated into the company’s existing Test Hub platform before Reflect’s generative AI capabilities are added to other platforms.

    Reflect provides access to a natural language interface to create tests using multiple large language models (LLMs) that it is designed to invoke. It can also understand the intent of a test to understand what elements to test regardless of whether, for example, a button has been moved from one part of a user interface to another, said Mishra. Test step definitions, once approved, can also be automatically executed using scripts generated by the platform.

    SmartBear has no plans to build its own LLMs, said Mishra. Rather, the company is focusing its efforts on providing the tools and prompt engineering techniques needed to effectively operationalize them, he added.

    Reflect is the tenth acquisition SmartBear has made as part of an effort to provide lightweight hubs to address testing, the building of application programming interfaces (APIs) and analysis of application performance and user experience. Last year, the company acquired Stoplight to gain API governance capabilities.

    Rather than building a single integrated platform, the company is focused on providing access to lightweight hubs that are simpler to invoke, deploy and maintain, said Mishra. The overall goal is to meet IT teams where they are versus requiring them to adopt any entirely new monolithic platform that requires organizations to rip and replace every tool they already have in place, he said.

    There is little doubt at this point that generative AI will have a profound impact on application testing in a way that should ultimately improve the quality of the applications. As the time required to create tests drops, more tests will be run. Today, it’s all too common for tests not to be conducted as thoroughly as they should be simply because either a developer lacked the expertise to create one or, with a delivery deadline looming, they simply ran out of time.

    Naturally, the rise of generative AI will also change how testing processes are managed. It’s not clear how far left generative AI will push responsibility for testing applications, but as more tests are created and run, they will need to be integrated into DevOps workflows.

    Of course, testing is only one element of a DevOps workflow that is about to be transformed by generative AI. DevOps teams should already be identifying manual tasks that can be automated using generative AI as part of an effort to further automate workflows that, despite commitments to automation, still require too much time to execute and manage. Once identified, DevOps teams can then get a head start on redefining roles and responsibilities as generative AI is increasingly operationalized across those workflows.

  • Diffblue Integrates Generative AI-Based Testing Platform With GitLab

    Diffblue Integrates Generative AI-Based Testing Platform With GitLab

    Diffblue this week generally made available an integration between its automated unit testing platform for Java and the DevSecOps platform from GitLab.

    The Diffblue Cover platform makes use of generative artificial intelligence (AI) to automatically create unit tests based on reinforcement learning technologies that don’t rely on LLMs—avoiding their drawbacks of sometimes introducing hallucinations and also requiring human review.

    Diffblue CEO Mathew Lodge said the integration with the continuous integration capabilities found in the premium and ultimate editions of the GitLab platform would, for example, streamline regression testing in a way that should ultimately improve both application quality and security. Diffblue Cover, for example, can update tests as much as 250 times faster than a human developer can write them manually without developer review.

    That approach also serves to reduce the level of friction many DevSecOps teams encounter when bottlenecks involving testing processes emerge, noted Lodge. The overall goal is to make it simpler for developers to test as much of their own code as possible before integrating it into a build, he added. Otherwise, developers will get fed up because testing is continuously breaking the build, noted Lodge.

    Ultimately, instead of having to write unit tests, developers become supervisors of a platform that automatically generates them on their behalf, said Lodge. The job of a developer doesn’t go away, but it does fundamentally change, he added.

    To achieve that goal, developers need to be able to access a platform that writes the tests and can then also execute them automatically. If it takes too long to create the test, chances are high that most developers won’t run it. On average, writing and evaluating a single unit test can take a developer 10 minutes. Over the course of any project, thousands of tests need to be written, so the amount of time testing takes away from coding is often much greater than most IT leaders fully appreciate.

    Automating those tests should improve developer productivity as more time is available to focus on writing code rather than testing. That doesn’t necessarily eliminate the need for a dedicated testing team, but it does mean that more tests will be run without slowing down the overall pace of application development.

    Developers naturally want to be able to test code at the very instant they create it. AI platforms can make that happen by, for example, employing reinforcement learning to write unit regression tests.

    Most developers are not going to resist assuming more responsibility for testing if the tools to automate that task are more accessible. Instead of merely shifting responsibility for testing left toward developers, DevOps teams need to find ways to streamline the process. Otherwise, testing just becomes one in a series of tasks that are being shifted to developers in ways that many of them are coming to resent.

    It may take some time before AI is fully integrated into software engineering but it’s clear with each passing day more previously manual tasks are being automated. Among the lowest hanging fruit for applying AI to software engineering are clearly testing processes that, if truth be told, few indeed enjoy conducting.

  • 5 Security Threats DevOps Teams Should Know

    5 Security Threats DevOps Teams Should Know

    DevOps security, also known as DevSecOps, is a philosophy in which security practices are integrated into the DevOps process. DevOps security involves creating a ‘security-as-code’ culture with ongoing, flexible collaboration between release engineers and security teams. The DevSecOps movement, much like DevOps itself, is focused on creating new solutions for complex software development processes within an agile framework.

    DevOps security is about breaking down silos and promoting open collaboration across teams. It’s about making everyone accountable for security with the ultimate aim of improving the quality and speed of code releases. The adoption of a DevOps security model necessitates a cultural shift across the organization. It requires the integration of security into every aspect of the development and operations processes.

    DevOps Security is not just about implementing tools and technologies; it’s about changing the way we look at security. Rather than being an afterthought, security should be a key part of the ongoing conversation from the start of the project to the end.

    5 Security Threats DevOps Teams Must Know About

    As a DevOps professional, it’s crucial to be aware of the potential threats that could compromise your systems, applications, and data. Let’s take a look at the top five security threats that DevOps teams must be aware of.

    Phishing Attacks

    Phishing attacks are a common security threat that can lead to data breaches. These attacks involve cybercriminals impersonating legitimate organizations to trick individuals into revealing sensitive information, such as passwords and credit card numbers.

    Phishing attacks can be particularly damaging for DevOps teams. They can lead to unauthorized access to development systems and data, which can lead to devastating supply chain attacks. For example, an attacker could trick a team member into revealing their login credentials for a critical system, allowing the attacker to gain access and inject malware into a CI/CD pipeline.

    Code Injection

    Code injection is another common security threat that DevOps teams must be aware of. This involves the exploitation of an application by injecting malicious code. The attacker can then execute the malicious code to compromise the system or steal sensitive data.

    For DevOps teams, code injection attacks can be particularly harmful. These attacks can lead to compromised systems and applications, resulting in data breaches and significant downtime.

    Man-in-the-Middle Attacks

    Man-in-the-middle attacks are a type of security threat where the attacker intercepts and potentially alters the communication between two parties without their knowledge. This can lead to a range of damaging outcomes, including data theft, session hijacking, and even identity theft.

    For DevOps teams, man-in-the-middle attacks can be particularly problematic. These attacks can lead to compromised systems and data, and even the unauthorized alteration of code.

    Container Vulnerabilities

    Container vulnerabilities are a significant security threat for DevOps teams. Containers are a key technology in the DevOps world, allowing for the rapid and reliable deployment of applications. However, like any technology, they come with their own set of security risks.

    These vulnerabilities can range from use of insecure images, to misconfigurations and software bugs, to more serious issues like kernel exploits. If an attacker is able to exploit a container vulnerability, they could potentially gain control over the entire system.

    DDoS Attacks

    Last but not least, distributed denial-of-service (DDoS) attacks are a significant security threat that DevOps teams must be aware of. These attacks involve overwhelming a production environment with traffic, causing it to become unavailable to users.

    For DevOps teams, DDoS attacks can be particularly damaging. Not only can they lead to significant downtime, but they can also result in lost revenue and damage to the organization’s reputation.

    How to Mitigate These DevOps Security Threats

    While these security threats are concerning, there are effective strategies and techniques that can be used to mitigate them.

    Implement Email Security Practices and Tools

    To combat phishing attacks, it’s crucial to implement email security tools that can detect and block phishing attempts. These tools can help to filter out phishing emails, reducing the likelihood that team members will fall victim to these attacks.

    In addition to implementing email security, it’s also important to provide security awareness training for team members. This training should cover the basics of cybersecurity, including how to recognize and respond to phishing attempts.

    Use Input Validation and Sanitization in Applications

    To protect against code injection attacks, it’s important to use input validation and sanitization in applications. Input validation involves checking that the data provided by a user meets certain criteria before it’s processed by the application.

    Input sanitization, on the other hand, involves cleaning up the data to remove any potentially harmful elements. This can help to prevent malicious code from being executed within the application.

    Employ HTTPS and SSL/TLS Encryption for Data in Transit

    To guard against man-in-the-middle attacks, it’s important to employ HTTPS and SSL/TLS encryption for data in transit. This ensures that any data being sent between the user and the application is encrypted, making it much more difficult for an attacker to intercept and read the data.

    Regularly Scan Containers for Vulnerabilities

    To protect against container vulnerabilities, it’s crucial to regularly scan containers for vulnerabilities. This involves using tools that can analyze the containers and identify any potential security risks.

    By regularly scanning containers, DevOps teams can identify and address vulnerabilities before they can be exploited by an attacker.

    Implement Rate Limiting and Network Filtering

    Finally, to mitigate the risk of DDoS attacks, it’s important to implement rate limiting and network filtering. Rate limiting involves restricting the number of requests that a user can make to the application within a certain period of time.

    Network filtering, on the other hand, involves blocking traffic from certain IP addresses or ranges that are known to be associated with DDoS attacks. This can help to reduce the impact of a DDoS attack and protect the availability of the application.

    In conclusion, DevOps security is a crucial aspect of the DevOps process. By being aware of potential security threats and taking steps to mitigate them, DevOps teams can significantly reduce the risk of a security breach and ensure the ongoing success of their projects.

  • Venafi Adds Ability to Prevent Unauthorized Code From Running

    Venafi Adds Ability to Prevent Unauthorized Code From Running

    Venafi added an ability to prevent unauthorized code from running in IT environments that make use of its machine identity management platform.

    Shivajee Samdarshi, chief product officer at Venafi, said the Stop Unauthorized Code Solution leverages the company’s CodeSign Protect offering to ensure that only authorized code can run on any given platform.

    The overall goal is to enable organizations to better secure their software supply chains using a zero-trust approach to software based on identity management and code signing to verify software comes from an approved source and complies with policy controls, he added.

    All code is signed using private digital certificates or those issued by trusted certificate authorities, said Samdarshi. Before code can execute, the security platforms an organization has in place can be configured to check that digital signature against trusted code signing certificates, he noted.

    Interest in securing software supply chains has risen sharply since the Biden administration issued an executive order requiring federal agencies to implement a range of measures, including code signing, to achieve that goal. However, securing software chains is often more challenging than organizations initially appreciate.

    In fact, a recent Venafi survey found that 70% of security and IT leaders believe that software supply chain attacks are their biggest security blind spot. Additionally, 85% believe that continuous security validation of the CI/CD pipeline is vital to reduce the risk of vulnerabilities going undetected during the software development lifecycle. A full 88% said they believe machine identity management is essential to the success of zero-trust models that are being more widely adopted across enterprise IT environments.

    Arguably, the most important thing organizations need to focus on is making sure application developers and cybersecurity professionals develop a working relationship. The biggest barrier to the adoption of DevSecOps best practices required to secure software supply chains remains largely cultural. For more years than anyone cares to admit, many developers have viewed cybersecurity more as a hindrance to application development that needs to be overcome or circumvented rather than being a core aspect of a quality assurance process. The total number of vulnerabilities that exist in applications running in production environments could likely be measured in the billions.

    Remediating all those vulnerabilities may never be practical, but at the very least, DevSecOps teams could make sure that no new code containing vulnerabilities is allowed to execute. Cybercriminals have become especially adept at inserting malware into code that they hope will find its way into any number of downstream applications before they activate it. That capability alone should help mollify cybersecurity teams that are increasingly being tasked with improving software supply chain security. The challenge is those cybersecurity teams don’t always appreciate the impact new policies can have on the pace at which applications are developed and deployed.

    Like it or not, software supply chains will generally be more secure in 2024. The only thing that remains to be determined is how much friction will be injected into DevSecOps workflows to achieve that goal.

  • Configuration-as-Code: Trends and Predictions for 2024

    Configuration-as-Code: Trends and Predictions for 2024

    Configuration-as-code, often abbreviated as CaC, is an innovative approach to managing and provisioning computing resources. It refers to the practice of handling changes, deployments and updates to software and systems via code rather than manual processes. CaC allows for a version-controlled, reproducible and automated method of managing environments, leading to more consistent and reliable systems.

    The essence of configuration-as-code is to treat system configurations the same way that software code is treated. This means that configurations are written in a code format, stored in a version control system and applied through automated processes. This approach brings several benefits, including consistency, repeatability and the ability to test changes before applying them to live environments.

    This concept is not just a theoretical approach but rather a practical tool for managing modern digital infrastructure. It’s a key component of DevOps practices, enabling teams to move faster while maintaining control and minimizing the risk of operational issues. Configuration-as-code is a critical tool for managing complex systems and achieving the highest levels of operational efficiency and reliability.

    The Evolution of CaC in Recent Years

    Over the past several years, configuration-as-code has grown from a niche concept into a mainstream practice adopted by many leading technology companies. This evolution has been driven by several factors, including the increasing complexity of digital systems, the rise of cloud computing and the broader adoption of DevOps practices.

    In the early days, system configurations were often managed manually or through ad-hoc scripts. This approach was prone to errors, hard to scale and lacked visibility into changes. As systems grew more complex, the need for a more robust, scalable, and reliable method of managing configurations became apparent. This led to the creation of configuration-as-code.

    The rise of cloud computing has been a significant driver in the adoption of configuration-as-code. With cloud platforms, resources can be provisioned and managed via APIs, making it possible to handle configurations through code. This has allowed for much greater scalability and flexibility enabling companies to manage large, complex environments more effectively.

    The adoption of DevOps practices and increasingly mature automation frameworks have also contributed to the growth of Configuration as Code. As infrastructure-as-code (IaC) becomes the norm, CaC is becoming a staple of modern DevOps practices.

    Trends in Configuration-as-Code for 2024

    Looking ahead to 2024, several trends are likely to shape the future of configuration-as-code:

    Increased Adoption of Cloud-Native Environments

    As more companies adopt cloud-native technologies, the use of configuration-as-code is set to increase. Cloud-native environments are inherently dynamic and complex, making them an ideal fit for configuration-as-code. With CaC, teams can manage these environments more effectively, ensuring consistency, scalability, and reliability. Cloud-native technologies like Kubernetes and Docker also natively support configuration-as-code, making it easier for teams to adopt this approach.

    Use of AI and Machine Learning in Configuration Management

    Artificial intelligence and machine learning are set to play a significant role in the future of configuration management. With AI and ML, teams can automate even more aspects of configuration management, reducing the risk of human errors and freeing up time for more valuable tasks. For example, AI could be used to predict the impact of configuration changes, while machine learning could help automate the process of optimizing configurations for performance and cost efficiency.

    Shift Toward Immutable Infrastructure

    Immutable infrastructure means that servers are never modified after they’re deployed. Instead, any changes are made by deploying a new server with the desired configuration. This approach reduces the risk of configuration drift and ensures a consistent environment. Configuration-as-code is a key enabler of immutable infrastructure, making it easier to manage and deploy servers in a repeatable, automated way.

    Collaboration and Democratization of CaC

    Finally, the trend towards collaboration and democratization in technology will also influence configuration-as-code. With CaC, configurations become more visible and accessible, allowing for greater collaboration between teams. This can lead to better decision-making, less siloed working, and improved overall outcomes. At the same time, configuration-as-code also enables democratization by making it easier for non-technical stakeholders to understand and participate in configuration management.

    Predictions for Configuration-as-Code in 2024

    CaC is Becoming a Cornerstone in the DevSecOps Approach

    The integration of development, security and operations—commonly known as DevSecOps—aims to embed security practices into the DevOps process. As we look towards 2024, configuration-as-code is set to become a cornerstone in the DevSecOps approach.

    By treating infrastructure as code, teams can apply the same security practices they use for application code to their infrastructure. This includes performing code reviews, using automated testing, and tracking changes to the environment. With configuration-as-code, security can shift left—being considered earlier in the development process—leading to more secure systems.

    Moreover, configuration-as-code can help bridge the gap between security and operations teams. It allows for a shared language and shared tools, fostering better collaboration and communication.

    Growth of CaC-as-a-Service

    Configuration-as-code-as-a-service is an emerging trend that is set to grow significantly by 2024. This approach allows businesses to outsource configuration management to a specialist third party, which uses configuration-as-code to automate the process. Cloud-based configuration management solutions provide advanced capabilities such as secrets management, centralized configuration management and orchestrated workflows.

    Version Control Features Specifically Designed for CaC

    Version control systems are a key component of configuration-as-code. They allow teams to track changes to their environment, revert back to previous versions if necessary, and collaborate more effectively. In 2024, we can expect to see the evolution of version control systems with features specifically designed for CaC.

    These features might include support for infrastructure-specific languages and better integration with infrastructure tools. Version control tools might also introduce improved support for collaborative configuration workflows, making it easier for teams to work together on infrastructure configuration.

    Increased Role of CaC in Managing Edge Computing Environments

    As we move into 2024, we can expect to see an increased role for configuration-as-code in managing edge computing environments. Edge computing is rapidly growing due to its ability to bring computation and data storage closer to the location where it is needed, improving response times and saving bandwidth.

    With the rise of edge computing, managing these environments becomes increasingly complex. CaC can automate the process of setting up and maintaining these environments, reducing human error and increasing efficiency. This also allows for consistency across different environments, leading to more reliable systems.

    In conclusion, the future of configuration-as-code looks promising. As we move towards 2024, we can expect to see an increased role for CaC in managing edge computing environments, its evolution as a cornerstone in the DevSecOps approach, the growth of CaC-as-a-Service, and the evolution of version control systems specifically designed for CaC. These developments promise to bring about greater efficiency, security and collaboration in the realm of infrastructure management.

  • Mobb Extends DevSecOps Reach of Tool to Generate Patches

    Mobb Extends DevSecOps Reach of Tool to Generate Patches

    Mobb today added an ability to instantly surface patches for vulnerabilities at the time when code is being committed during a DevSecOps workflow.

    Previously, the tool provided by Mobb to create validated patches based on the scan results of third-party SAST tools would only surface issues to individual developers.

    Mobb CEO Eitan Worcel said organizations can now address these issues within the context of DevSecOps workflow.

    The Mobb platform combines proprietary security research and traditional semantic analysis with generative artificial intelligence (AI) to automatically create patches for vulnerabilities. The overall goal is to make it simpler for DevSecOps teams to consistently ensure applications with known vulnerabilities are remediated before they are deployed, said Worcel.

    The Mobb approach eliminates the need for IT teams to sort through static application security testing (SAST) scans themselves. Each vulnerability typically requires at least 30 minutes to fix, so the Mobb platform improves application security while simultaneously making developers more productive.

    Historically, one of the reasons for the wide divide between application development teams and cybersecurity professionals is that many of the vulnerabilities discovered don’t actually impact applications running in production environments. Development teams then find themselves wasting time investigating vulnerabilities and, when they do determine a vulnerability is an issue, spending time developing a patch. The Mobb tool automatically creates the necessary patch, so there is less of a need to debate which vulnerabilities are worthy of the time required to create a patch.

    For decades, application development teams have been attempting to find a way to remediate vulnerabilities as quickly as possible. With increased focus on adopting DevSecOps best practices to address those vulnerabilities, more organizations are now reviewing software supply chains as part of a larger effort to improve application security.

    There will, of course, be vulnerabilities that the Mobb tool will not be able to address simply because there may not be enough affected applications to warrant pre-building a patch. Even with the most robust set of rules, it is improbable that an automated tool can, with 100% certainty, safely fix every issue. However, given the number of routine vulnerabilities present in applications, such as SQL injections, there’s plenty of opportunity to improve developer productivity by relying on patches that address common vulnerabilities.

    The process by which patches are prioritized, developed and then applied has, of course, long been a source of DevOps frustration. Anything that streamlines that process will go a long way toward improving the overall state of application security at a time when cybercriminals are becoming more adept at exploiting vulnerabilities. The challenge is finding a way to remediate vulnerabilities that developers will embrace rather than resist. The Mobb approach still provides them with control over what patches are applied but the toil involved with creating a patch in the first place has been substantially reduced.

    It’s not clear how long it might be before automated approaches to building patches might improve the overall state of application security but, as always, every journey needs to begin with a first step in the right general direction.