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.

  • Applying TestOps to Cultivate a Quality Culture

    Applying TestOps to Cultivate a Quality Culture

    Quality assurance is a universal concern, especially when it comes to application development. Enterprise applications are faster and more reliable than ever before. However, in addition to performance, application developers also must consider data security, regulatory compliance and cost-effectiveness, among other things. Organizations are embracing quality engineering (QE) as a foundation to create a software quality culture to address these challenges. Creating a quality engineering or TestOps environment is not simple, especially when QE departments must test for hundreds of applications across multiple enterprise environments. Whether it is a solution provider or a multinational corporation, applications often need to be tested across platforms, industries and geographies.

    TestOps encompasses a broader concept than just QE. With TestOps, there are testers and engineers using automated and manual testing to validate software for flawless application performance. In enterprise DevOps, the TestOps team serves as the bridge between development and deployment since they have a good understanding of the applications and a better perspective on the context and variables that can affect performance.

    Continuous testing is an integral part of any software development cycle. Quality engineers must be brought in early as part of Agile development to keep development on track and head off any problems that could escalate or become harder to resolve later. In Agile, testing becomes more crucial and frequent to ensure flawless performance.

    It pays to think horizontally when setting up a TestOps approach. For example, testing should be performed across different vertical environments such as media, manufacturing and finance. The goal is to create a test environment that can accommodate various industries.

    TestOps Across Environments

    In the age of SaaS and universal data access, it is essential to test across multiple platforms. In addition to ensuring enterprise performance, mobile web and remote data access must be tested. For streaming services, it is vital to test across mobile platforms, over-the-top (OTT) platforms such as Roku, Apple TV, Android TV and Fire TV, and even gaming consoles like PlayStation and Xbox.

    When shipping software updates, geography matters (especially when shipping across time zones), as one may never know when the software will be used or have control over the environment where they plan to use it.

    For instance, consider the challenges a leading mortgage lender faced with mobile application testing and how geography was a factor. First, Google Analytics was used to assess specific device and user requirements and ascertain performance in various parts of the United States since different regions use different carriers. Testing was then done across mobile platforms such as iOS, Android and combinations and across carriers since most banking and mortgage applications required one-time passwords (OTPs) and SMS-related capabilities. Further tests were implemented for new identity authentication strategies such as biometrics and facial recognition. Finally, performance testing by geography was conducted to determine whether a new feature or version would create issues.

    Testing for Geographies and Regional Compliance

    Localization testing is important since every region and every country has unique compliance issues and laws. To ensure proper localization, it is essential to perform complete testing, including lower environments and production systems.

    In any TestOps environment, the philosophy of continuous testing should already be part of the design environment, including understanding the nuances of production. Release readiness does not mean there are only a few known bugs in certain regions. It means the application has been tested for compliance in every geography where it could possibly be utilized.

    Testing Across Industries

    Testing application performance in specific industry settings brings along its own set of unique challenges. In manufacturing, for example, each sensor in an IoT device must be modeled against a conformance specification to determine if it can be automated using simulations. In media, one needs to test for different platforms, content management systems and business workflows.

    To accelerate time to market, one would want to support a dual-shift development lifecycle to gauge the consumer experience and get continuous feedback and also need a test environment with multiple automation tools such as Selenium, Appium, Cypress, Tricentis, UiPath, Test Complete and Winium.

    Artificial intelligence (AI) plays a larger role in testing, shortening time to market, and ensuring superior quality software. AI-driven test tools are optimized for domain-specific applications, such as testing for industries like media, manufacturing and fintech. AI can fill in the gaps to achieve optimization and offer a quicker turnaround with limited manual intervention.

    Any organization cultivating a TestOps culture needs to have specific technologies and tools in place. When assessing your testing technology stack, it is important to create an end-to-end testing ecosystem. This means the environments must be inclusive and capable of incorporating testing for unique applications, environments and scenarios. To support the needs of today’s Agile application development environment, one must plan for an agile testing infrastructure to keep development on track.

  • CircleCI Integrates CI/CD Platform With GitLab

    CircleCI Integrates CI/CD Platform With GitLab

    CircleCI today announced it has integrated its continuous integration/continuous delivery (CI/CD) platform with a rival software-as-a-service (SaaS) offering from GitLab.

    DevOps teams can now, for example, trigger pipelines in CircleCI from GitLab forked merge requests in addition to merging requests and making commits for specific branches. Other capabilities include the ability to access testing capabilities on the CircleCI platform and integrate permissions to ensure security.

    CircleCI CEO Jim Rose said the company routinely integrates its CI/CD platform with other offerings because organizations typically have multiple teams using different version control platforms at different times. The goal is to give those teams access to capabilities and best practices regardless of which specific platform they are using.

    In general, Rose said organizations are trying to strike a balance between the standardization of DevOps platforms and the need to enable development teams to innovate by adding new tools. Standardization tends to create more opportunities to automate more tasks in ways that reduce costs. However, developers will eventually rebel against any effort to limit the choice of tools they use to improve productivity, noted Rose. Too many senior IT leaders are quick to assume that a plethora of tools is an indication of a problem rather than the result of ongoing experimentation, he added.

    In the wake of the global economic downturn, many organizations are also revisiting their existing DevOps workflows to try to increase overall efficiency by automating more tasks. Those organizations realize they can’t afford to continue throwing labor at manual DevOps tasks, Rose added.

    The challenge, of course, is that building and deploying modern software is becoming more complex. Organizations are embracing microservices to make applications more resilient as they realize how dependent they are on software. The issue is that as the number of microservices continues to expand, it becomes apparent that legacy manual processes will not scale, said Rose. As a result, the impetus to automate DevOps processes becomes that much greater, he added. Less clear is to what degree organizations that have already embraced DevOps platforms might be willing to swap out their current CI/CD platform to achieve that goal.

    In the meantime, more organizations are embracing DevOps to manage software development projects that drive a wide range of digital business transformation initiatives. The applications driving those processes typically need to be continuously updated as business requirements change. That becomes much easier to achieve when using processes optimized around continuous development and deployment.

    Regardless of which underlying CI/CD platform organizations choose, they should assume that, eventually, some level of integration between those platforms will be necessary. After all, in the event of an acquisition, for example, it’s not likely both companies will have standardized on the same DevOps platform. Given the amount of time required to migrate from one DevOps platform to another the amount of time required for interoperability is inevitably going to be measured in months if not years.

  • Empathy for the API Developer

    Empathy for the API Developer

    Security teams have always been perceived as an impediment to delivery by software teams who feel that security imposes arbitrary and unreasonable policies and use poorly-integrated tools that are beset with high false-positive rates. With the advent of DevOps, security has been seen as an increasing obstacle to rapid deployment cycles. 

    Security teams believe developers do not care about security and will try their best to avoid security controls or policies. Security teams are often frustrated by developer pushback when remediating vulnerabilities, particularly when they fail to appreciate the cascading effects of making code and dependency changes late in the life cycle.

    From my perspective, with a foot in both camps and a decade of experience helping developers produce more secure code, I believe the key to addressing the disconnect between teams is to develop greater empathy for the developer.

    Why Insecure Software Exists

    Software development is a complex endeavor with many (often conflicting) requirements. Blaming software developers for insecure software is an overly simplistic and counterproductive approach, best summarized by a former colleague:

    “I can tell you that virtually all developers I talk to care about application security. They care about the quality of the products they create, the integrity of the data their software handles, and the reputation of the organizations they work for.” —  Jim Jastrzebski, Veracode

    From my experience, developers don’t deliberately set out to create insecure software; instead, there are a number of reasons it happens.

    Devs are overly optimistic: Developers are creative folks and natural problem-solvers. They can often visualize the perfect end result of their labor without necessarily considering the technical and security debt they may encounter along the way. Remember—things do go wrong.

    Overconfidence: I often refer to this as the Dunning-Kruger effect for developers. Faced with complex platforms, languages and frameworks, developers tend to overestimate their ability to comprehend and master them. Complex systems take time to fully understand and being overly confident can lead to unintended consequences and compromise security. Beware of insecure defaults and configurations.

    Bad things only happen to other developers: Think of this as a kind of schadenfreude for developers. During code reviews with developers, I have been surprised to hear comments like, “ … But that won’t happen to my code!” Despite vast evidence to the contrary, some developers think that bad things only happen to others and to others’ code. Assume a defensive mindset; expect the worst and hope for the best.

    Taking shortcuts: Developers are goal-oriented and want to produce working code on schedule. And schedules are tight. The inevitable consequence is that sometimes shortcuts are taken (missing error handler or input validation, for instance) leading to security vulnerabilities. Track and tackle your technical debt.

    Technical debt or legacy code: Speaking of technical debt, it’s probably one of the biggest issues facing developers: The burndown of technical debt and maintenance of legacy code. Software systems are complex and minor changes may wreak havoc, especially in microservices-based applications and architectures. Remember that developers may have legitimate concerns about making changes that are not absolutely necessary.

    This stuff is difficult: The biggest thing to remember to develop the empathy muscle is to appreciate the difficulty of the software development process. Developers are facing multiple conflicting requirements against tight deadlines and are required to master a variety of technologies. Mistakes will happen; the important thing is to learn lessons and improve the process.

    The last point is perfectly captured by this quote:

    “90% of security problems are just complexity problems. It’s technical complexity, it’s network complexity, it’s organizational complexity.” — Adrian Ludwig, Atlassian

    Care and Feeding of Developers

    Once security engineers have a better understanding of the challenges facing developers, they can focus on their messaging when communicating about security issues. Remember that the developer is unlikely to be personally responsible for every issue and should not be blamed or scolded. This will produce defensive behavior and is unlikely to achieve a positive outcome. Focus on the shared security challenge at hand and how a joint approach can solve the problem.

    A frequently-cited problem for developers is the relatively high false-positive rates security tools produce, particularly with code scanning tools. Security engineers should make sure that the tools are suited to your technical stacks and fine-tune the tool as much as possible. Ideally, the security team should triage the initial report and remove obvious false positives. 

    Additionally, certain legacy security tools do not integrate well into CI/CD pipelines and cannot be easily automated within the build process. If a developer has to use a manual or asynchronous process to perform a security scan, they will become frustrated and possibly ignore this requirement. Make sure security tools work well with the developer’s environments and workflows.

    Do not assume every developer has a deep understanding of the security issues identified—take the time to explain them thoroughly and/or document them internally. A great approach is to conduct shared learning sessions where developers and security teams work through a vulnerable application together to learn the concepts.

    Another frustration developers cite is a lack of clear understanding of the security requirements or requirements that are constantly changing. Ensure security policies are clearly stated and available to developers, and explain the reasons why the policies exist in the first place—for example, to meet PCI DSS accreditation. 

    Finally, make sure the combined teams are given time not just to learn but to absorb lessons and that success is recognized and rewarded. 

    “The sky is always falling—we never celebrate success.” – Chris Romeo, Security Journey

    Empowering Developers

    So, what does developer empathy look like for API developers?

    First, API developers and security engineers can both benefit from the positive security model that uses the OpenAPI definition as the contract for API behavior. Anything not specified by that contract is considered invalid—in other words, the contract specifies the allow list. This is in stark contrast to the traditional approach for web security which is reliant on blocking according to a block list—obviously, not all bad input can be known leading to false negatives with this approach. Overly aggressive blocking may block valid input and typically result in false positives; familiar to users operating web application firewalls (WAFs).

    The OpenAPI definition offers another advantage: The applicable policies can be expressed as code in the definition as opposed to via some verbose, abstract policy documentation. The benefit of policy-as-code is to uniformly enforce policy across the life cycle starting when the developer first starts coding the API. 

    Finally, developers need security tools that work in their preferred environments (for example, first-class IDE and CI/CD plugins) and provide value in the form of remediation guidance or actionable findings that help developers reduce technical debt. 

    Security and development don’t have to be at odds; help developers to help themselves by building empathy and working with them rather than against them.

  • Poor App Remediation Creates a Vicious Vulnerability Cycle

    Poor App Remediation Creates a Vicious Vulnerability Cycle

    A survey of 200 security professionals found nearly 83% of respondents reported that an increase in the rate at which applications are being deployed has led to an increase in the reintroduction of previously remediated vulnerabilities.

    The survey, conducted by Waratek, a provider of tools for managing security-as-code, found 93% of the security professionals polled currently work for organizations that have embraced DevOps or Agile development methodologies. Half of the respondents (50%) described maintaining security in those environments as challenging, with a slightly higher percentage (58%) noting that implementing security within DevOps process does slow down the rate at which applications are deployed. A full 85% also noted that manual security work slows the rate at which applications can be deployed as well.

    Surprisingly, more than two-thirds (67%) of security professionals also said they would be willing to sacrifice security to allow applications to be delivered on time.

    Nearly three-quarters (71%) also said they expected that keeping pace with DevOps teams would only become more difficult, with 61% also noting that keeping pace with DevOps teams resulted in delays to other critical security projects.

    Waratek CEO Doug Ennis said the root cause of the application security challenge can be traced back to continued reliance on manual processes. It’s too easy for developers, for example, to reuse code that contains vulnerabilities that were fixed in one version of an artifact but not another, he noted.

    That lack of automation also conspires to increase overall cybersecurity fatigue, added Ennis. More than 50% of survey respondents reported they spend days or weeks each year investigating false positives. There simply are not enough cybersecurity professionals available to make sure applications are secure without relying more on automation, said Ennis.

    In the wake of a series of high-profile security breaches, there is more focus on software supply chain security than ever. However, it’s not clear to what degree organizations are embracing automation and DevSecOps best practices to secure those software supply chains. The challenge is finding a way to build more secure applications without slowing down the rate at which those applications are built and deployed.

    Many organizations are clearly already shifting more responsibility for application security left toward developers and DevOps teams with hopes of achieving that goal. However, it’s still the cybersecurity team that get the call whenever there is a breach, noted Ennis. There must be workflows in place that enable automatic remediation in ways that don’t always require organizations to wait on a developer to build and deploy a manually-applied patch that is usually inconsistent, he added.

    The Log4Shell vulnerability is a perfect example of how flawed the current process for building and deploying patches is, Ennis explained.

    In fact, as more applications are deployed, developers often find themselves spending more of their time fixing vulnerabilities than they do writing new code. A new approach to building and deploying secure applications that leverages automation is clearly required. The challenge is creating automation that consistently achieves that goal each and every time required in a way that doesn’t break any of the applications that need to be fixed.

  • 3 New WFH and Hybrid Work Trends That YOU Need to Grok

    3 New WFH and Hybrid Work Trends That YOU Need to Grok

    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, a remote/hybrid work special: Bribes to relocate you, Fridays are forgotten, and big tech firms stop building offices. (more…)

  • Atlassian Bitbucket CI/CD Cloud Service Aims for the Enterprise

    Atlassian Bitbucket CI/CD Cloud Service Aims for the Enterprise

    Atlassian today outlined its strategy to increase the appeal of the Bitbucket continuous integration/continuous delivery (CI/CD) cloud service among enterprise IT organizations. Atlassian said it plans to focus on four core pillars: Performance, management, extensibility and security and compliance, starting with an update scheduled for the third quarter.

    Dan Tao, head of engineering for Bitbucket Cloud and Compass at Atlassian, said the overall goal is to make it simpler to use the Bitbucket Cloud service running on the Amazon Web Services (AWS) cloud at scale as organizations increase the rate at which they build and deploy software.

    Atlassian is still supporting the Bitbucket Server and Data Center editions of the platform, but it’s apparent more organizations are shifting software development to the cloud, he noted. Atlassian is now moving to not only simplify migrations to the cloud by, for example, providing a Bitbucket Cloud Migration Assistant tool, but it is also moving to ensure applications can be developed at scale.

    Achieving that goal includes making use of a more advanced diff algorithm that is four times faster in larger DevOps environments, he added.

    Other planned enhancements include the ability to execute CI/CD workflows via Bitbucket pipelines, the ability to reuse multi-step pipelines across repositories, tighter administration integration with other Atlassian applications, the ability to encrypt data at rest and integration with the Snyk tool for discovering vulnerabilities in software to improve security.

    Finally, the Bitbucket Cloud service will also soon support Bitbucket Mesh, a distributed storage capability that is already employed in Bitbucket Data Center.

    Overall, Atlassian sees the migration to the cloud as a means to not only make DevOps workflows more accessible to a wider range of organizations, but also give organizations that have already invested in DevOps the opportunity to streamline those processes, said Tao.

    Many DevOps teams today maintain complex platforms with custom integrations that they need to maintain and support. Atlassian provides DevOps teams the option to either employ an integrated platform or use connectors it has created as part of the Atlassian Open DevOps framework to make it simpler for teams to use whatever mix of tools they prefer, he added. In either case, the total cost of maintaining a DevOps environment can be significantly reduced, said Tao.

    It’s not clear to what degree organizations that have already invested in DevOps are considering replacing their existing CI/CD platforms. However, as the pressure to accelerate the rate at which software is built and deployed steadily increases, the pressure to further automate DevOps workflows also builds. At the same time, DevOps teams are now being asked to integrate security gateways that require additional custom integrations within legacy platforms that they would need to support alongside existing integrations.

    At the very least, more organizations than ever are weighing their DevOps options. The issue, of course, is that the total cost of switching out DevOps platforms is not inconsequential given the current dependency on existing workflows.

  • To Prevent Supply Chain Attacks, Build Secure Code

    To Prevent Supply Chain Attacks, Build Secure Code

    More than a year after the massive SolarWinds cyberattack, targeted companies continue to feel its ramifications in both reputation and financial cost. Moreover, the global software supply chain remains vulnerable to severe attacks, whether from a hostile nation-state like Russia–now increasingly in the cybersecurity spotlight due to fears of retaliation due to U.S. sanctions–or from any other cybercriminal party. 

    As long as the world continues to choose fast over secure, nothing is safe. No one knows how many potential backdoors the SolarWinds attack alone created, which could allow the persistent presence of malicious actors on a seemingly infinite number of networks; nor do we know when the next attack will happen with potentially more dire consequences. For example, six months after the discovery of the Log4j vulnerability and its associated patches, we know that networks and products all over the world remain unpatched, vulnerable and exploitable in all sorts of companies both big and small.

    This must change. And that change must start from the inside out; meaning programmers, developers and DevOps teams should start building code more securely in the first place. That also means that those who use cloud services, third-party black box software or the services of hub companies, whose networks connect both suppliers and customers, should better understand how code development affects security. This increased focus on the underlying technology itself will not completely prevent attacks, but it will reduce the number of attacks.

    There are signs that the industry is moving in this much-needed direction—or that there are at least more discussions about it. The White House recently hosted meetings with technology experts focused on this very topic. And this spring, the SEC announced that it may begin requiring some companies to report cyberattacks within four days and also provide details about their cybersecurity posture. This increased government attention is raising awareness and could also open the door to regulations, or at least universal best practices for coding protocols. But regardless of eventual, still-hypothetical regulation, developers—and cybersecurity professionals at hub companies—should give serious thought to the process they use to securely build their products. 

    Beyond Open Source Code

    Of course, an oft-recommended solution is to move to open source software (OSS). Although open source code is still vulnerable to attacks, the processes and practices involved in creating OSS code are transparent, which goes a long way toward crippling the ability of bad actors to conceal themselves. But such an approach will never work on a large scale in the private sector as there is no way to prevent programmers from simply copying others’ novel code, leaving no way to protect intellectual property among software developers.

    However, there are other steps that could be nearly as effective, including integrating security features and testing into development tools and processes. For example, making gray and black box penetration testing a routine part of the software production process would go a long way in helping find vulnerabilities in the code that outsiders could find and access. Ideally, developers could then also remedy or repair these vulnerabilities. Also, assessing security at every step of the development process could give crucial insights into vulnerabilities before they are discovered in the wild by malicious actors.

    Code-Signing and Scanning Innovations

    Implementing other methods to spot security flaws in code, including in open source code, would also help. Using innovations like code-signing would alert developers if any changes were made to the code before they use it, helping to spot hackers or backdoors before the code is implemented into the product. In addition, developing better source code scanning technology is important for flagging vulnerabilities. Developers should also undergo training focused on building a product with a secure life cycle and implementing security protocols for merging and accessing the product code; this could prevent cyberattacks from occurring as a result of a faulty (or nonexistent) SDLC process—the same way an electrical engineer couldn’t design a building electric plan without formal training and certification and participating in regular continuing education and recertification. 

    CISOs Need to Be Proactive

    CISOs and IT professionals also have an active role to play. They need to evaluate the security of their products’ underlying code , taking full advantage of the software bill of materials (SBOM), which lists all components of software (and that could soon be required by law) but that is only one side of it. This needs to be coupled with measures like code signing, scanning for flaws and keeping an updated list of components to spot newly-published weaknesses and vulnerabilities in libraries and frameworks. And it is increasingly important to make sure that contracts with software service providers specify they are adhering to secure development practices. 

    With the world on high alert and the private sector especially vulnerable to state-sponsored cyberattacks, there has never been a better time to focus on building more secure code. This does not mean that all of the other aspects of cybersecurity—including  threat intelligence, incident response plans and hiring and retaining talented professionals—will be any less important. But if the code underlying the software can itself become more secure, these attacks could become fewer in number and their damage less far-reaching. 

  • Survey Warns of Looming Software Testing Crisis

    Survey Warns of Looming Software Testing Crisis

    A survey of CEOs and IT professionals involved in application testing finds a significant gap in terms of how acceptable it is to release software that has not been properly tested.

    The survey, conducted by the market research firm Censuswide on behalf of Leapwork, a test automation platform provider, polled 480 CEOs in the U.S. and the United Kingdom (UK) from organizations with more than 500 employees and 480 heads of quality assurance, testers, release and delivery managers and site reliability engineers (SREs).

    A full 85% of the CEOs in the U.S. and 69% in the UK said it’s acceptable to release software that hasn’t been properly tested, as long as patches are tested and applied later. Less than half of the IT professionals surveyed (49%) agreed. A full 94% of CEOs also said they’re confident the software released is tested regularly.

    However, 79% of the IT professionals admitted that as much as 40% of software goes to market without sufficient testing. As a result, 68% of UK and 52% of U.S. IT professionals said their teams spend five to 10 days per year patching software.

    The survey also made it clear that everyone involved is well aware of the risks that lack of testing creates. Nearly every CEO (95%) is concerned about losing their job in the wake of a software failure. Slightly more than three-quarters of the IT professionals (76%) surveyed have the same fear.

    More than three-quarters of CEOs (77%) also noted that software failures have harmed their company’s reputation in the last five years.

    Many organizations today assume that Agile development and DevOps best practices will enable them to apply patches quickly in the event an issue arises. The trouble is, in the absence of sufficient testing many of those organizations are essentially experimenting on end users.

    Leapwork CEO Christian Brink Frederiksen said the primary reason so much software is not being properly tested is that most organizations continue to rely on manual testing processes that can’t keep pace with the rate at which applications are now being developed; one major factor is the use of low-code and no-code tools.

    Of the IT professionals at organizations that release insufficiently-tested software, a full 40% cited underinvestment in test automation as a factor, with only 43% of respondents using some type of automation. Other reasons cited for the lack of appropriate testing included lack of time (34%) and increased rates of deployment (29%).

    Just over a third of CEOs (34%) and about four in 10 testers (42%) whose companies use or develop in-house software that goes to market without being tested also cited a lack of available skilled developers. More than a third of CEOs (34%) also cited underinvestment in testing personnel.

    At a time when more organizations than ever are dependent on software to drive digital business transformation initiatives, it’s apparent that an application testing crisis is imminent. The only thing left to be determined is how catastrophic the fallout will be because existing processes don’t scale to meet the challenge.

  • Red Hat CEO: Out | Blind Users: Revolt | ARM: Google Joins Party

    Red Hat CEO: Out | Blind Users: Revolt | ARM: Google Joins Party

    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: Matt Hicks is the new Red Hat CEO, visual accessibility is in focus, and Google Cloud rolls out ARM instances. (more…)

  • Security Compass Makes Visualizing AppSec Threats Simpler

    Security Compass Makes Visualizing AppSec Threats Simpler

    Security Compass this week updated its threat modeling platform for developers to make it easier to surface application security issues.

    The latest version of SD Elements 2022 adds support for developer-centric threat modeling diagrams, reusable components, more advanced reporting capabilities and 114 more just-in-time training (JITT) modules. In addition, Security Compass has now integrated its platform with the Black Duck software composition analysis (SCA) tool.

    Drew Koelemay, director of product management for Security Compass, said the goal is to make it easier for application development and cybersecurity teams to collaborate using a platform that visualizes cybersecurity threats within a DevOps workflow.

    That approach to application security is critical because it becomes easier for developers to understand how changes to applications improve the overall cybersecurity posture of complex app environments where there are lots of dependencies, he said.

    Once that visualization is achieved it then becomes possible to create reports highlighting the most prevalent threats and weaknesses across that portfolio, Koelemay noted.

    In the wake of a series of high-profile application breaches, organizations of all sizes are looking to better secure their software supply chains by implementing DevSecOps best practices. The issue that immediately arises is the cultural divide between application development teams and cybersecurity professionals. The Security Compass platform surfaces developer-centric visualizations of security issues to help bridge the historic divide that exists between those teams, said Koelemay.

    For the most part, cybersecurity professionals view development teams’ lack of cybersecurity expertise to be the root cause of many of the issues they encounter. It’s not that a developer deliberately sets out to build and deploy vulnerable applications. By the time the application is reviewed—often just a few days before it’s supposed to be deployed—it’s often too late to do much about most of the vulnerabilities that are discovered. Cybersecurity professionals and application development teams need to meaningfully engage each other much earlier in the application development life cycle.

    The simple truth is developers are not likely to reach out first simply because they don’t know what cybersecurity issues to look for in an application environment. Most of the time they are rushing to meet an application delivery deadline, which makes them perceive cybersecurity as a hurdle to overcome rather than an automated process integrated within their workflow. Cybersecurity professionals, therefore, need to find a way to more constructively engage developers. The onus is on cybersecurity teams to insert themselves at the front end of the application development process rather than waiting at the backend for an inevitable issue to arise.

    One way or another, application security is going to improve. The only thing yet to be determined is how painful the process will be. Tools that enable DevOps teams to see for themselves what issues are being encountered should go a long way toward reducing both the level of pain being experienced and the amount of time required to resolve the cybersecurity issue at hand.