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.

  • mabl Adds Load Testing Tool to Test Automation Suite

    mabl Adds Load Testing Tool to Test Automation Suite

    mabl today added a load testing capability to its portfolio of application testing tools that it makes available via a software-as-a-service (SaaS) platform.

    That capability promises to make it simpler to streamline testing within a DevOps workflow by making available load testing tools that measure application peformance alongside existing mabl tools accessible via a test automation platform.

    Dan Belcher, mabl CEO, said the goal is to make it simpler for developers to run functional and non-functional tests as early as possible within the software development life cycle.

    It’s not clear how much responsibility for testing is shifting left toward developers, but as it becomes simpler to run these tests it is more likely they will be run, noted Belcher. One of the core issues that plagues application development today is the inadequate level of testing. That issue is largely because it takes too much time to create and run relevant tests, he added.

    mabl streamlines that process using a test automation platform based on a low-code tool that makes it simpler to create and manage the testing process. Those tests can be configured to run independently or be integrated with a DevOps pipeline, noted Belcher.

    Shifting testing further left toward developers doesn’t eliminate the need for a dedicated team of testers, but it should reduce the number of routine errors being made. That reduction should free those development teams to focus more of their time and effort on more complex quality assurance (QA) issues, said Belcher.

    Of course, more testing processes will become automated as artificial intelligence (AI) continues to evolve, so most organizations will soon find themselves revamping those processes. In theory, SaaS platforms that aggregate testing data should be in a better position to apply AI models to testing. That’s critical because the pace at which even more complex applications are being built and deployed shows no sign of slowing down.

    In the meantime, DevOps teams should assume they will soon be held more accountable for security issues that arise after an application is deployed. It may be a while, but the number of legislative initiatives focused specifically on application security has increased; it’s only a matter of time before laws that hold organizations liable for security are going to be passed. At the same time, the level of tolerance application software consumers have for issues that arise because some trivial mistake led to, for example, a SQL injection attack, is dropping. The expectation is that application testing is soon going to be a lot more thorough than it has historically been.

    The issue, of course, is that too many development teams tend to view security requirements as obstacles to be overcome rather than as intrinsic elements of the QA process that is supposed to ensure expectations are consistently met and exceeded.

    At this juncture it’s clear that application testing is going to improve. The only thing left to determine now is how much friction will be experienced on the way to achieving that goal.

  • Cycode Adds ASOC Module to Streamline DevSecOps Workflows

    Cycode Adds ASOC Module to Streamline DevSecOps Workflows

    Cycode has added a module to its platform for mapping metadata and events using graph technology that makes it simpler for application development and cybersecurity to consolidate alerts generated by their DevSevOps tools.

    Lotem Guy, vice president of product for Cycode, said the Cycode Application Security Orchestration and Correlation (ASOC) module will automatically discover all the tools that make up a DevSecOps workflow without requiring any integration effort.

    That capability makes it simpler to aggregate results in a way that enables development teams and cybersecurity professionals to identify the most critical issues that need to be addressed before applications are deployed in production environments, he added.

    In effect, Cycode is now providing a method for bridging the historic divide between cybersecurity professionals and application development teams. More cybersecurity professionals are embedded within DevOps teams, but in the absence of a platform for aggregating alerts, they often encounter communications issues. ASOC provides an agentless approach to aggregating the data that DevSecOps teams need to prioritize remediation efforts, said Guy.

    While a lot of progress has been made in terms of adopting DevSecOps best practices, many organizations still struggle with securing their software supply chains. Most of the members of a DevOps team have limited cybersecurity expertise, so they need the help of a cybersecurity professional to determine what specific actions are required to remediate a vulnerability. Cybersecurity professionals, conversely, don’t have a lot of application development expertise and generally would prefer not to be overwhelmed by multiple DevOps tools generating alerts about the same potential application security issue.

    As the number of regulations specifically focused on application security steadily increase, it’s now just a question of time before every organization that builds software will need to embrace DevSecOps. The challenge is that while everyone involved generally agrees software should be more secure before it’s deployed, the security tools made available to DevOps teams vary widely. In fact, it’s not uncommon for DevOps teams to find themselves spending significant amounts of time sorting through multiple conflicting alerts.

    Nor is every alert that gets generated relevant—in some cases, a specific module that generated an alert might not find its way into the final application. In addition, many of the alerts generated also tend to lack context about severity. Application developers can’t devote all their time to fixing bugs, so choices will need to be made based on the actual risk to the application.

    Cycode is betting that, as DevSecOps continues to evolve, organizations will look for tools and platforms that make it simpler to make sense of the current level of application security chaos that tends to pervade IT organizations. In the meantime, cybersecurity professionals and application developers will need to learn to trust one another. Developers have too often viewed cybersecurity as an obstacle to deployment while cybersecurity teams have historically considered developers to be one of the primary causes of the breaches they are expected to clean up. The first step toward achieving that goal is, of course, to realize that neither is really the enemy of the other.

  • DORA Report 2022: The Magnitude of Software Supply Chain Security  

    DORA Report 2022: The Magnitude of Software Supply Chain Security  

    The term ‘software supply chain security’ (SSC) can be interpreted in many ways. Following the White House executive order in May 2021 and the European Cyber Resilience Act (CRA) of 2022, both governments and corporations are taking a more active role in ensuring their software is secure. Fundamentals such as having a software bill of materials (SBOM) and being able to cross-reference it with known common vulnerabilities and exposures (CVEs) are now the standard, but supply chain security covers far more than just the software that builds your products.

    To create certainty and clarity, leading standardization bodies such as OWASP, OpenSSF and others have set up ongoing efforts to define and mitigate SSC threats. They have active working groups, SIGs and TACs all working in vendor-neutral ways to help define and solve parts of the SSC problem.

    A great example of this is the continuous work being done by Google Cloud’s DevOps Research and Assessment (DORA) initiative. More specifically, the subject was reflected in the September 2022 DORA report that focused on security in general and supply chain security in particular. Using the Supply-chain Levels for Secure Artifacts (SLSA) framework as well as the NIST’s Secure Software Development Framework (SSDF) as benchmarks for actively addressing supply chain security issues, the researchers assessed how organizations were successful in approaching and addressing threats at all levels of the organization.

    My view of the major findings of the DORA report are summarized below.

    Who Owns Software Supply Chain Security?

    The report stated that organizations should empower individual teams and developers to “own” security while administering a consistent security policy and posture across its products. While I agree with this, we need to examine both sides of the ‘ownership’ coin. By nature, this hybrid approach creates complexity—and even friction—between the security team that, by definition, is responsible for all facets of security and the developers that are being tasked to ‘fix’ security issues in addition to their daily tasks. There has to be common ground between developers, their tasks associated with security and the security team.

    Individuals in organizations that build software care about what they build; they have a stake in the overall success of the final product and this feeling of ownership strengthens that level of care. However, asking for such ownership while adding a security component to the mix without providing sufficient knowledge, tools, proofs, and “power” to make decisions could lead to  a lack of trust, confusion, execution problems and frustration. To alleviate this, the security team should provide developers the tools, education and resources they need to feel empowered to enhance security efforts at the source. Organizations that provide evidence in a scalable, digestible manner are successful in building trust and creating common ground between the developer, security and the security team.

    There’s also another dimension that could potentially create silos between developers and security teams rather than bringing the two together: There’s no one single security team or owner of SSC. SSC is tricky to define as a category; it involves shift left security, runtime security and everything in between. Some portions of it are being governed by the security office, some by AppSec, some by DevOps and some by the developer. The ownership of each isn’t well-defined and the entire effort is very difficult to consolidate as one process or methodology. In addition to upskilling the developer with tools and training, long-term education, thought leadership and access to good technology are the keys to gradually reduce these friction points..

    Security Processes Slow Down Development

    Defining the tools, methodologies and processes that should be employed in an organization to add sufficient security while not impacting development speed is not a trivial task.

    ­­The following are four principals I think correspond well with the SLSA framework and that help address the development slowdown challenge:

    Set preventive measures: Avoid using known vulnerable and malicious packages from the beginning of development. By eliminating vulnerabilities introduced in first-party code (due to bad coding practices) as well as misconfigurations, wrong encryption and secrets exposures, you are preventing known threats from entering your product.

    Examine proactively and continuously: The security state of software changes because the software itself always evolves and new vulnerabilities are continuously being introduced. It makes a software artifact that was just secured suddenly become susceptible to attack. This requires continuously rescanning and revisiting software artifacts as well as frequently recalculating any potential risk.

    Set preemptive measures: Create a plan that initiates a prompt response when a potential risk is discovered. Both development and security teams should create the plan for decision making and execution. The measures should include ways to identify vulnerable artifacts across development and production, how to understand exploitability and true impact and how to prioritize and remediate accordingly.

    Do it all in an automated manner: Create automated processes based on reliable data and scanning tools to dramatically reduce the effort needed by developers and DevOps teams.

    DORA report co-author Eric Maxwell said one of the main principles is to remain tool- and platform-agnostic while focusing on capabilities and practices. From that perspective, automation is essential and it is enabled by security-as-code. Having a common language–code–allows teams to communicate about security as well as collaborate. It drives the things we discussed earlier around democratizing the security process and helps break down silos.

    The DORA findings—alongside the topics described above—encourage community awareness and continued shared efforts to bring much-needed attention to software supply chain security. Gradually, SSC security will evolve, but as it does so, the only way to properly address it is by ensuring the developers and security teams are on the same page and both have ownership of responding to and resolving issues as they appear. For more in depth review of the DORA report I encourage you to view Leap Left for Security: The DORA Report Roundtable.

  • GitLab Survey Reveals DevSecOps Gains

    GitLab Survey Reveals DevSecOps Gains

    A global survey of 5,010 IT leaders, CISOs and developers published by GitLab this week found well over half (56%) of respondents are working for organizations that are using DevOps or DevSecOps practices. However, 72% of respondents said they are using a DevSecOps platform (36%) or are considering adopting one in the next year (36%).

    Overall, less than a third of survey respondents (30%) said they were “completely” responsible for application security, with 53% reporting they are part of a larger application security team. Well over a third (38%) of the 1,453 security professionals surveyed said they are part of a cross-functional team focused on security.

    License compliance checks and security capabilities for cloud-native or serverless tied for the top of the list of current priorities (19%), but shifting security left (29%) was the top focus for the coming year. Nearly three-quarters (74%) of security professionals said their organizations either shifted left or plan to in the next three years. Nearly as many (71%) said a quarter or more of all security vulnerabilities were discovered by developers.

    Top frustrations identified specifically by security professionals included testing happening too late in the development cycle (43%) and difficulty prioritizing vulnerability remediation (41%).

    Those frustrations might increase in the coming year, with 85% of security professionals reporting they either have the same or lower budget in 2023.

    On the plus side, nearly two-thirds of the 1,954 developers surveyed said they are either using artificial intelligence (AI) and machine learning (ML) algorithms in testing today or will be in the next three years. A full 62% said they used AI/ML to check code, while 53% use bots for testing and 36% use AI/ML for code review.

    Nevertheless, more than two-thirds of security professionals (67%) said they are concerned about the impact of AI/ML capabilities on their job, with 28% of them admitting they are “very” or “extremely” concerned. Of those respondents who expressed concern, 25% said they are worried about the potential for AI/ML to introduce errors that will make their job more difficult.

    David DeSanto, chief product officer at GitLab, said GitLab is also working to address those concerns by embedding a range of AI/ML capabilities into its platform to optimize DevSecOps workflows and, most recently, enhanced its GitLab Remote Development module to make it easier to centralize the maintenance and security of development environments.

    GitLab this week also announced it is partnering with Oracle to make it easier to use the GitLab continuous integration/continuous delivery (CI/CD) platform to run AI and ML workloads on the Oracle cloud platforms. AI/ML is going to play a critical role in enabling organizations to build and deploy secure code without slowing down the pace of application development, said DeSanto. In fact, many organizations will soon be consolidating toolchains to enable them to achieve that goal, he added.

    The GitLab survey found 57% of security respondents said they use six or more tools, but many of those tools are legacy software composition analysis (SCA) tools that will be replaced as more responsibility for application security shifts left toward developers, noted DeSanto. Two-thirds of survey respondents (66%) reported they want to consolidate their toolchains this year.

    Collectively, the GitLab survey makes it clear that DevOps and DevSecOps practices and platforms continue to evolve rapidly. The challenge, as always, is keeping up with the pace of that change.

  • Continuous Testing: The Key to Quality Assurance in the DevOps Era

    Continuous Testing: The Key to Quality Assurance in the DevOps Era

    Continuous testing has emerged as a critical aspect of quality assurance in the DevOps era. In recent years, there has been a rapid transformation in software development methodologies. With the advent of DevOps, there has been a significant shift toward automation and continuous integration and delivery (CI/CD). The traditional approaches to quality assurance are no longer adequate to meet the needs of modern software development practices. Continuous testing is the key to ensuring that the software is delivered on time, with quality and reliability.

    Definition of Continuous Testing

    Continuous testing is a process of executing automated tests continuously throughout the software development life cycle to provide rapid feedback on the quality of the code. It is an essential component of DevOps that ensures that the software is always ready for release. Continuous testing allows for the detection of defects and errors at an early stage, which reduces the risk of production issues and enhances the overall quality of the software.

    Importance of Continuous Testing in DevOps

    To understand the importance of continuous testing in DevOps, it is essential to understand the evolution of quality assurance in software development.

    Traditional Waterfall Method

    The traditional waterfall model of software development had a sequential approach to quality assurance. Testing was only performed after the development phase was completed. This approach often led to delays and increased costs due to detecting defects later.

    Agile Methodology

    The Agile methodology introduced an innovative approach to quality assurance. Testing became an integral part of the software development lifecycle, and the focus was on continuous feedback and improvement. However, even with Agile, testing was still done in batches, and there was a significant amount of manual testing involved, which could be time-consuming and prone to errors.

    DevOps Model

    The DevOps model took the concept of continuous feedback and improvement to a new level. With DevOps, testing became automated, and continuous integration and delivery became the norm. This approach significantly reduced the time to market, increased collaboration between development and operations teams, and enhanced the overall quality of the software.

    The Role of Continuous Testing in DevOps

    Definition of DevOps

    DevOps is a software development methodology that emphasizes collaboration and communication between development and operations teams to deliver software products rapidly and reliably. It involves the integration of development, testing and operations into a continuous process, with automation as a key enabler.

    Importance of Continuous Testing in DevOps

    Continuous testing is a critical component of DevOps. It enables the testing of software continuously throughout the development lifecycle, which helps to identify defects and issues early on.
    This early detection of issues is essential in reducing the risk of production issues, and it allows for timely feedback, which facilitates faster decision-making.

    Benefits of Continuous Testing in DevOps

    There are several benefits of continuous testing in DevOps, including:

    · Faster time to market: Continuous testing enables the rapid release of software, reducing the time to market significantly.
    · Improved collaboration: DevOps emphasizes collaboration between development and operations teams, and continuous testing facilitates this collaboration by providing continuous feedback on the quality of the code.
    · Enhanced quality: Continuous testing enables the early detection of defects and issues, which reduces the risk of production issues and enhances the overall quality of the software.
    · Reduced costs: Continuous testing can help to reduce costs by identifying defects and issues early on, which reduces the cost of fixing issues later in the development cycle.

    Implementing Continuous Testing in DevOps

    Choosing the Right Test Automation Tools

    The selection of the right test automation tools is critical to the success of continuous testing in DevOps. Some of the popular test automation tools for DevOps include Selenium, Appium, Cucumber and JUnit.

    It is essential to choose a tool that is easy to use, integrates well with other DevOps tools, and has strong community support.

    Building an Effective Test Automation Framework

    An effective test automation framework is essential to implementing continuous testing in DevOps. A test automation framework is a set of guidelines and standards that help in the creation and execution of automated tests.

    A good framework should be modular, flexible, and scalable. It should also be easy to maintain and extend as the project grows.

    Integrating Continuous Testing Into the DevOps Pipeline

    To implement continuous testing in DevOps, testing should be integrated into the DevOps pipeline. The DevOps pipeline is a series of steps that automate the software development process, from code commit to production release.

    Continuous testing should be integrated into every stage of the pipeline, from unit testing to acceptance testing.

    Best Practices for Continuous Testing in DevOps

    To achieve the full benefits of continuous testing in DevOps, it is important to follow best practices. Some of the best practices for continuous testing in DevOps include:
    · Test early and often: Testing should begin early in the development cycle and continue throughout the development process.
    · Automate everything: Automation is essential for continuous testing in DevOps. All tests should be automated, including unit tests, integration tests and acceptance tests.
    · Integrate testing into the DevOps pipeline: Testing should be integrated into every stage of the DevOps pipeline, from code commit to production release.
    · Use the right test data: Test data should be relevant and representative of real-world scenarios.
    · Collaborate across teams: Collaboration between development, testing and operations teams is essential for the success of continuous testing in DevOps.

    Challenges and Solutions for Continuous Testing in DevOps

    There are several challenges to implementing continuous testing in DevOps, including:
    · Test data management: It can be challenging to manage and maintain relevant test data that accurately represent real-world scenarios.
    · Test environment management: Ensuring that the test environment is consistent and reliable can be a challenge, especially in complex applications.
    · Test automation maintenance: Test automation scripts can become complex and challenging to maintain, especially as the application evolves.

    Strategies for Overcoming Continuous Testing Challenges

    There are several strategies for overcoming the challenges of continuous testing in DevOps, including:
    · Test data management: Creating synthetic test data can help ensure that the data is relevant and representative of real-world scenarios.
    · Test environment management: Using containerization technology such as Docker can help ensure a consistent and reliable test environment.
    · Test automation maintenance: Regular maintenance and refactoring of test automation scripts can help keep them up-to-date and relevant.

    Conclusion

    Continuous testing is the key to ensuring quality in the DevOps era. It enables the rapid release of software, reduces the risk of production issues and enhances the overall quality of the software. Implementing continuous testing in DevOps requires choosing the right test automation tools, building an effective test automation framework, integrating testing into the DevOps pipeline and following DevOps best practices. Although there are challenges to implementing continuous testing in DevOps, these challenges can be overcome with the right strategies and practices. By implementing continuous testing in DevOps, organizations can achieve faster time to market, improved collaboration, enhanced quality and reduced costs.

  • AI Chatbots: Game Changers for DevOps Transformations

    AI Chatbots: Game Changers for DevOps Transformations

    In today’s fast-paced digital world, organizations are constantly looking for ways to accelerate their software development processes and ensure the seamless integration of their development and operations teams. DevOps has emerged as a popular methodology to achieve this goal, but even with its adoption, many companies still face challenges in their transformation journey. AI chatbots can revolutionize DevOps transformations, making them more efficient and effective than ever before.

    How AI ChatBots Improve DevOps Transformations

    Enhance collaboration by automating routine tasks and facilitating communication between teams: AI chatbots can handle repetitive tasks, freeing up team members to focus on more critical issues while also providing a centralized communication hub for both development and operations teams.
    Expedite incident management by providing real-time alerts and smart recommendations: AI chatbots can analyze logs and system metrics to quickly identify issues and suggest the most appropriate resolution steps, reducing downtime and improving overall system performance.
    Streamline deployment and monitoring processes using AI-driven automation: AI chatbots can intelligently manage deployment pipelines, ensuring that the right code gets deployed to the right environments while also monitoring system health and performance in real-time.
    Offer real-time analytics and insights into the development pipeline for informed decision-making: AI chatbots can gather and analyze data from various sources, providing valuable insights that help teams make better decisions related to code quality, release schedules and resource allocation.
    Identify skill gaps and recommend targeted training resources for continuous improvement: AI chatbots can analyze team performance and individual skill sets, helping organizations identify areas for improvement and providing personalized learning resources to close those gaps.

    Roadmap to Implement AI Chatbots in DevOps Transformations

    Evaluate your organization’s current DevOps maturity and identify areas for improvement: By assessing your existing processes and infrastructure, you can better understand the gaps where AI chatbots can make the most significant impact.
    Select an AI chatbot platform that aligns with your organization’s technology stack and goals: Choose a platform that complements your existing tools and supports your specific DevOps objectives to ensure seamless integration and adoption.
    Define and prioritize use cases for AI chatbot implementation in your DevOps processes: Identify the key areas where AI chatbots can provide the most value, such as incident management or deployment automation and prioritize their implementation accordingly.
    Develop a phased implementation plan that includes integration, testing and deployment of AI chatbots: Create a step-by-step plan to integrate AI chatbots into your existing DevOps processes, ensuring proper testing and validation at each stage to minimize potential disruptions.
    Train your teams on how to leverage AI chatbots effectively and continually refine their usage based on feedback and performance metrics: Provide education and training resources to help your team members understand how to use AI chatbots to their full potential and foster a culture of continuous improvement.

    Benefits of AI Chatbots in DevOps Transformations

    AI chatbots offer several benefits that can significantly improve DevOps transformations, including:

    Increased efficiency by automating manual tasks and streamlining processes: This leads to faster development cycles, quicker releases and a more agile response to changing business requirements.
    Enhanced collaboration and communication among development and operations teams: AI chatbots can break down silos between teams, fostering a more collaborative and unified approach to software development and delivery.
    Faster incident resolution and reduced downtime: With AI chatbots’ help, issues can be identified and resolved more quickly, minimizing the impact on end users and maintaining a high level of service quality.
    Real-time insights into the development pipeline for more informed decision-making: AI chatbots enable teams to make data-driven decisions by providing real-time analytics and insights into various aspects of the development process, such as code quality, resource allocation and release timelines.
    Continuous learning and improvement through AI-driven recommendations: By identifying skill gaps and suggesting targeted training resources, AI chatbots can help teams continuously improve their knowledge and expertise, ultimately leading to better performance and more successful DevOps transformations.

    Summary

    In conclusion, AI chatbots are poised to revolutionize DevOps transformations by addressing common challenges, enhancing efficiency and fostering a culture of continuous improvement. By automating routine tasks, facilitating communication and providing valuable insights into the development pipeline, they can significantly improve the effectiveness of DevOps processes. As organizations continue to adopt and refine their DevOps strategies, incorporating AI chatbots into their workflows will become increasingly essential to remain competitive in the ever-evolving digital landscape.

  • Report: Most IT Teams Can’t Fix Open Source Software Security

    Report: Most IT Teams Can’t Fix Open Source Software Security

    Lineaje, a provider of a platform for securing software supply chains, today published an analysis of 41,989 open source components embedded in the top 44 popular projects managed by the Apache Software Foundation (ASF). That analysis found more than a quarter (26%) of vulnerabilities are not patchable by the application development team that deployed them.

    In addition, the report found that 64% of the vulnerabilities analyzed have no patch as of yet. Overall, 68% of the vulnerabilities analyzed are due to dependencies created when an open source software project included a component or package developed by another open source project maintainer.

    Lineaje CEO Javed Hasan said that means that 90% of open source dependencies are transitive, in the sense that they are created when maintainers of a project included a vulnerable open source component created by another entity. Only 10% of the vulnerabilities discovered by Lineaje are the result of a dependency that an application development team could actually address on their own, he added.

    Overall, the report found a full 82% of components that are relied on to build open source software are inherently risky due to vulnerabilities, security issues, code quality or maintainability concerns. In addition, 5% of components failed a basic integrity check, with 3% having no known origin.

    Open source software is not created equal no matter what consortium is overseeing its development, noted Hasan. Unfortunately, there is no universally accepted method for validating the integrity of open source software, so application development teams should proceed with caution whenever employing open source software, he said.

    The challenge, of course, is that developers have been reusing open source software within applications for years now. It’s only in the recent wake of breaches involving open source software that organizations have been taking a harder look at how applications are developed.

    The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, is now at the forefront of an effort to better secure open source software by focusing on 10 streams of investment that, in total, will require more than $150 million in funding to drive greater adoption of DevSecOps best practices among maintainers of open source software projects. The issue is that many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited. The onus for making sure open source software is secure when deployed in a production environment belongs to the organization that deploys it.

    Hopefully, following a recent executive order issued by the Biden administration, the level of open source security will steadily improve in the months ahead—assuming, of course, the organizations that rely heavily on open source software make more substantive contributions to securing it. In the meantime, organizations can count on the fact that cybercriminals have taken note of the vulnerabilities in applications that can be traced back to flaws in a wide range of open source software.

  • Mobb Launches Community Edition of Automated Remediation Tool

    Mobb Launches Community Edition of Automated Remediation Tool

    Mobb today made available a free community edition of a namesake tool that creates fixes to open source vulnerabilities. The fixes are based on the results of code scanning by a static application security testing (SAST) tool.

    Fresh from raising $5.4 million in seed funding, Mobb CEO Eitan Worcel said the company developed a tool that creates validated patches based on the scan results of third-party SAST tools from Checkmarx, GitHub and Snyk. Initially, the tool is aimed at Java vulnerabilities.

    Worcel said that most vulnerabilities can be traced back to eight types of mistakes that developers routinely make. The company created a pattern for those common mistakes, along with patterns to fix them, called Mobb rules. That ability enables Mobb to accurately produce a code fix that both remediates the vulnerability and adheres to the correctness of the language to eliminate code defects. Mobb then makes available a patch to address those issues in a way that can be readily downloaded and applied by developers. Mobb does not automatically apply those fixes because most developers prefer to review them first, noted Worcel.

    The Mobb approach eliminates the need for IT teams to sort through SAST scans themselves, which can result in the discovery of thousands of vulnerabilities that might theoretically need to be fixed. Each vulnerability, at minimum, is going to require 30 minutes to fix, so the Mobb platform provides a better return on investment and reduces patch backlogs, added Worcel.

    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 which types of vulnerabilities should have a higher remediation priority.

    Historically, one of the reasons for the wide divide between application development teams and cybersecurity professionals is that many of the vulnerabilities being 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 addresses that later issue by automatically creating the necessary patch, said Worcel.

    Many organizations just allocate junior developers to the task of remediating vulnerabilities, which Worcel noted frees up more experienced developers to focus on writing additional business logic.

    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 have already been developed.

    One way or another, the process by which patches are prioritized, developed and then applied has 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 wherever they may be found.

  • Turning Software Testers Into 10xers

    Turning Software Testers Into 10xers

    How do you make technical processes faster and more scalable? If your answer is simply to automate them, you’re stuck in the 2010s. Today, automation is widespread, and automating processes in a basic sense is no longer enough on its own to maximize efficiency and velocity. Instead, teams who want to excel–who want to become 10xers, so to speak–need to look beyond automation in its simplest form. They must take automation to the next level in a way that makes processes not just a little faster but orders of magnitude faster. Allow me to explain by discussing how software testers can put this principle into practice.

    The Limitations of Basic Test Automation

    When I talk about “automation in its simplest form,” I’m referring to automation that helps to execute core processes.

    In the context of software testing, basic automation means using frameworks like Selenium or Appium, which provide a way for engineers to execute tests automatically. That saves a lot of time and effort compared to executing each test manually.

    To be sure, there’s nothing wrong with simple automation. But the fact is that by now, most teams have caught on to the value that test automation provides. Automatically executing most of your tests no longer makes you much faster than average. It might have been a big deal a decade ago, back when test automation was less widespread, but it’s hardly enough to make you a 10xer today.

    Going Beyond Simple Automated Testing

    What does set you apart? What can testers do to supercharge their efficiency and velocity?

    The answer, again, is to take automation to the next level. Rather than simply using test automation frameworks to execute tests, they can also use automated tools to generate the tests in the first place.

    For example, modern automated testing solutions can automatically create test scripts based on actions that testers perform manually, making it possible to generate tests without having to write any code. That means you can create many more tests in much less time.

    As another example, next-generation automation can supercharge the interpretation of test results. If engineers want to know, for instance, when a screen finishes rendering in an application or when a crash occurred, they don’t have to parse test results manually, or write custom scripts, to find that information. They can leverage modern automation tools that collect that data on their own.

    In a similar vein, modern test automation tools can accelerate the process of troubleshooting tests that fail to run. For example, imagine that an automated test fails because it is supposed to test an element that developers relabeled in the newest version of an application. Traditionally, fixing that issue would have required engineers to review the test, sort through application code and then update the test with the new element ID. But this process could instead be automated using tools that can identify the application elements that a test should assess and update test scripts with the appropriate element IDs, all without requiring manual intervention.

    A Copilot-Inspired Approach to Software Testing

    You could draw analogies between the types of opportunities that modern test automation software makes available to testers and those that AI-powered tools like GitHub Copilot have opened up for software developers.

    If you’re a software developer today, you don’t have to settle for basic automation tools, like continuous integration servers (which automatically integrate code into larger codebases) or source code management platforms (which automatically track changes to code over time). You can also benefit from a new breed of automation tools, like Copilot, which can automatically generate code, unit tests and much more.

    For developers, Copilot is a prime example of a next-generation tool that can dramatically accelerate software development. Developers who learn to use Copilot effectively can work potentially ten times faster than their counterparts.

    The types of next-generation test automation solutions I’ve described above do the same thing for software testers. Instead of relying just on basic automation tools to run tests, modern testers have a host of additional, more powerful automation at their disposal to help create, manage, interpret and troubleshoot tests. Those who learn to use those tools will become the 10xers of today’s generation of software testers.

  • GitKraken App Correlates Activity Across Jira Cloud and Git Repositories

    GitKraken App Correlates Activity Across Jira Cloud and Git Repositories

    GitKraken today made available a preview of a free application that aggregates activity across Atlassian’s Jira Cloud and any Git repository to provide a unified view across all the activities of a software development team.

    Adam Wride, general manager for planning solutions of GitKraken, said Team Insights for Jira (TIJ) will make it easier for DevOps teams, project managers and application stakeholders to collaborate.

    TIJ accomplishes that goal by providing an overlay using a familiar Gannt chart view of epics and issues found in project management applications to correlate, for example, user activity such as status changes and comments made in Jira Cloud with updates to commits and pull requests made in a Git repository, he noted.

    Team members can then filter those views by project, sprint, contributors, issue type and other criteria to drill down on the exact list of issues that need to be addressed, added Wride.

    Most application development efforts rarely follow the original DevOps workflow plan, so TIJ provides a means for organizations to track real-time activity data to visualize how their efforts are progressing against the plan. That makes it possible to make data-driven decisions about how to reallocate resources as needed, said Wride.

    At the core of TIJ is a Git Integration tool that GitKraken previously made available. TIJ is the second offering from the company based on that tool following the launch of an application that integrates Jira with continuous integration/continuous delivery (CI/CD) platforms. GitKraken claimed there are already more than 10,000 organizations employing its Git integration tool.

    As more organizations become dependent on software to drive a wide range of processes, the need for increased visibility into DevOps workflows has become more crucial. Revenue is now directly tied to the pace at which software is being deployed and updated. Any change to the pace at which an application is being developed needs to be communicated across all the stakeholders that might be impacted. The challenge is that given all the dependencies that exist within modern applications, it’s not always easy to discern how a delay in the development of one module or component might impact multiple application development projects.

    Of course, project managers have been using project management applications to bring some order to the chaos of software development for decades. The challenge has always been that manual updates to projects have not always been provided in a timely manner. Developers don’t always remember to update project managers, who must manually enter updates in a project management application. GitKraken is making a case for an approach that automatically updates Jira Cloud by collecting data from DevOps tools and platforms rather than waiting for software engineers to remember to share that information with a project manager.

    Arguably, there’s now no excuse for everyone in an organization—if they care to, they can find out the status of any application development initiative. The challenge is making sure the data that DevOps teams—and their tools and platforms—already generate seamlessly updates the project management software that everyone else relies on to keep track of those projects.