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 Makes Move to Automate Accessibility Testing

    mabl Makes Move to Automate Accessibility Testing

    mabl today made available in beta an automated accessibility testing capability that it added to its software-as-a-service (SaaS) platform for testing applications.

    Dan Belcher, mabl co-founder, said given the increased accessibility requirements included in various compliance mandates, there is a greater need to address these issues as early as possible in the application development life cycle. Otherwise, organizations could find they are liable for failing to comply with accessibility requirements outlined in, for example, versions 2.0 and 2.1 of the Web Content Accessibility Guidelines (WCAG).

    At the same time, providers of applications that don’t address accessibility are also likely to find themselves called out on public social media forums, noted Belcher. The damage to brand reputation can be considerable, he added.

    The SaaS platform mabl created makes it possible to create reusable tests using a low-code engine dubbed axe-core. Those tests can then be inserted, as appropriate, into a DevOps workflow. That approach allows a dedicated testing team to create tests in a way that doesn’t need to occur on a DevOps platform, said Belcher.

    Regardless of regulatory requirements, Belcher said there is a clear need to include end users with disabilities within a digital universe that continues to rapidly expand. Unfortunately, as a whole, the software industry is only just starting to make accessibility a first-class concern, he added.

    The goal should be to enable fast feedback via accessibility regression tests that address, for example, contrast check, said Belcher. However, it’s not likely those tests are going to eliminate the need for periodic audits by accessibility subject matter experts as an application continues to evolve, he noted. Those reviews would address everything from the user interface to the overall performance impact, noted Belcher. It may possible, however, to one day address 50% of the accessibility issues identified in the WCAG guidelines via automation, he noted. Scanning code as it is being developed will prevent a backlog and a buildup of accessibility debt that would be much more costly to address after an application is deployed, added Belcher.

    In general, Belcher said, it’s not likely automation is ever going to entirely eliminate the need for dedicated testing teams. Testing platforms such as mabl are designed to enable a finite testing resource to keep pace with an accelerated rate of application development, he added.

    Accessibility is, for all intents and purposes, a subset of any comprehensive software quality review. The sooner development teams realize that fact the less likely they will find themselves apologizing in the future for not coming to that realization earlier.

  • The Pros and Cons of Embedded SREs

    The Pros and Cons of Embedded SREs

    To embed or not to embed: That is the question.

    At least, that’s one of the questions that companies have to answer as they decide how to implement site reliability engineering. They can either embed SREs into existing teams, or they can build a new, separate team.

    Both approaches have their pros and cons. The right strategy for your company or team depends, of course, on your needs and priorities.

    What is an Embedded SRE?

    An embedded SRE works as part of a non-SRE team. They might join development or IT operations teams, for example—although they could also be part of quality assurance teams, security teams or any other unit within the organization that can benefit from their expertise.

    Embedded SREs are the opposite of creating a dedicated, general-purpose SRE team. In the latter approach, an organization hires talent that collaborates with non-SRE teams but who aren’t integrated directly into them.

    There are several other organizational models that fall somewhere between these two poles. But typically, the two main types of structures are embedded or dedicated teams.

    Advantages of Embedded SREs

    Embedding SREs into other teams offers several benefits.

    Arguably the most important advantage is that embedded SREs ensure the highest level of collaboration between site reliability engineers and other stakeholders. When they work directly alongside other engineers on a continuous basis, it’s a pretty safe bet that their perspective will inform every decision that the other engineers make. Separate teams will still generally collaborate with other teams, but not necessarily with the same level of dedication as embedded SREs.

    Embedded SREs are also beneficial for organizations where the site reliability engineering concept remains new, and where stakeholders still need to learn what SREs do and the value they can bring. It may be a bit challenging to get buy-in when you propose creating an entirely separate team; indeed, developers or IT engineers may even perceive such a team as a threat to their own jobs (even though in reality, of course, they complement other teams instead of competing with them). But when you add SREs to larger teams, it’s likely to be easier to get everyone on board with the concept and for other types of engineers to appreciate how SREs make their jobs easier.

    Finally, embedded SREs work well for organizations that are on the small side and don’t need an entire team. If you have just several dozen engineers on staff instead of several hundred, hiring a few SREs to embed into your existing teams probably makes more sense than investing in a brand-new team.

    The Challenges of Embedded SRE

    The embedded model has its drawbacks, too.

    One major risk is that the SRE’s influence within a larger team may not be strong enough to have a major impact on how that team operates. A single SRE working alongside a dozen developers or IT engineers, for example, may struggle to integrate site reliability engineering techniques and tools into the existing team’s workflow—especially if it’s a team that already has strong opinions about how it should operate.

    Along similar lines, a single SRE working within a team using the embedded model could end up being stretched too thin to do his or her job well. That’s especially true if other team members expect them to “own” functions that should really be a collective, team responsibility—like responding to incidents or using chaos engineering to test reliability. The latter processes may be led by SREs, but they shouldn’t be their responsibility alone, and the function can start to break down when other team members think of them as the person on whom they can simply “dump” all of their reliability-related tasks.

    Finally, the embedded model can be difficult to scale, which is one reason why it doesn’t work as well at large organizations. If you have dozens of different engineering teams, embedding an SRE into each one requires a lot of management effort. It also deprives the various SREs within your organization of the ability to work closely with each other. In that type of scenario, it probably makes more sense to create a dedicated team and have those SREs interface with other teams as needed, rather than trying to distribute site reliability engineers across the business by embedding them directly into other teams.

    Conclusion

    In general, then, embedded SREs make most sense for companies that have relatively small engineering organizations, and in which the concept of the function has not yet received complete buy-in. For large businesses that have numerous engineering teams, it will likely be easier to manage SREs by creating a separate team just for them.

    That said, your mileage may vary from the norm, and it may be worth experimenting a bit to determine which model—embedded or not—makes the most sense for your company. Keep in mind that you can also use a hybrid approach wherein you embed SREs into some teams, while simultaneously maintaining a dedicated team that leads site reliability initiatives for the organization as a whole.

    After all, site reliability engineering is all about thinking creatively and coming up with innovative solutions to challenges—even the challenge of figuring out how to structure the SREs within your organization.

  • What’s the Difference Between SLI, SLA and SLO?

    What’s the Difference Between SLI, SLA and SLO?

    If you’re just getting into site reliability engineering (SRE) or platform engineering, you’ve probably come across a bunch of new terminologies, like SLI, SLA and SLO. These benchmarks are commonly referenced in the day-to-day life of an SRE but may seem foreign to outsiders. So, what are the differences between these abbreviations?

    Well, one of the hallmarks of the SRE approach is to gauge performance and set targets for application metrics. These targets can be thought of as reliability thresholds. If a site’s latency reaches a certain point, for example, it may break the agreement the software provider has with its consumer.

    SREs create and monitor service-level performance benchmarks for all sorts of metrics, such as uptime, latency, error count, mean-time-to-recovery and throughput, among others. But not all these performance goals are part of public agreements. Companies usually take a more proactive approach to setting more internal targets to stay far away from breaking external agreements and user trust. It’s become a best practice to set these baselines to retain functional, reliable systems.

    As mentioned, the type of targets range from firm partner commitments to more internal goals. Below, we’ll attempt to define, in simple terms, the differences between service-level agreement (SLA), service-level objective (SLO) and service-level indicator (SLI). While these concepts share many similarities, it’s important to understand how they are applied in practice. Keep in mind that each company may have a nuanced understanding of these terms and may conceive and apply them differently.

    Service-Level Indicator (SLI)

    First off, service-level indicators (SLIs) refer to the actual metrics produced by software services. This is a direct measurement of a service’s behavior. These are the real numbers that indicate overall performances, such as error rate and latency over time.

    One example of SLI would be the number of successful requests out of total requests over a one-month period. Say an engineer used an application monitoring tool that ingests data from production logs. This data showed that out of one million requests made, ten requests failed. An SLI for availability would thus be 99.999% uptime.

    Service-Level Agreement (SLA)

    Second, most technologists are familiar with service-level agreements (SLAs). Even if you’re not, you’ve likely agreed to many throughout your history as a digital user. SLAs are like a pact between the software provider and the software user or client. These binding commitments often note availability expectations that must be upheld. SLAs may also include responsiveness to incidents and bugs. It depends on the contract, but if an SLA is broken, some kind of penalty may be incurred such as a refund or a service subscription credit.

    These days, the average business relies on many cloud-based SaaS, PaaS and IaaS. Just to initiate something as simple as an online payment might require hitting multiple remote servers. But if all these services just went offline whenever they felt like it, our digital operations would come to a grinding halt. SLAs are thus necessary for enterprise software contractual agreements to ensure both parties meet specific standards.

    Once an engineer tracks SLIs and has an idea of typical behavior, they can then set an SLA that makes sense. If we take the example above, an SRE may consider guaranteeing a lower threshold than what is being actively monitored. This would ensure that application performance, at its current pace, doesn’t break any legal or contractual obligations. In this scenario, perhaps the SLA mentions an availability objective: No more than 100 requests fail per one million requests made. This would essentially equate to 99.99% uptime.

    Service-Level Objective (SLO)

    Lastly, service-level objectives (SLOs) are similar to SLAs but explicitly refer to the performance or reliability targets. An SLA may refer to specific SLOs. Or SLOs may be tracked just for internal purposes. As Google described, “the availability SLO in the SLA is normally a looser objective than the internal availability SLO.”

    You don’t want the end users to be the first people clamoring about a 400%+ latency rise in your mobile web apps. Thus, SRE teams typically keep a close eye on performance to ensure they never even get close to breaking SLAs. Some do this by setting and monitoring internal baselines that are more ambitious than the SLA threshold.

    If we take our example above, if an SLA guarantees a service uptime of 99.99%, the business may set an internal target of 99.995%. In other words, for every one million requests, no more than 50 should fail. If software systems aren’t hitting these marks, it’s a sign that the company must reevaluate designs and search for bottlenecks. Or, perhaps engineering teams have goals to improve the average downtime for the next quarter—an internal objective could be set at a higher standard than the currently perceived performance.

    As the Google Cloud blog described, “every service should have an availability SLO—without it, your team and your stakeholders cannot make principled judgments.” It’s a good reminder to be modest in your reliability commitments, they added, as consumers will come to expect this level of performance. On the other hand, setting more ambitious internal performance targets has the benefit of delivering a better result than the agreement on paper, increasing a software service’s competitiveness.

    Real-World Performance Benchmarks

    Keep in mind that the above numbers are simply for demonstration purposes. One interesting resource for real-world figures is API.Expert, a service that queries popular APIs and posts weekly performance statistics. Since APIs are the heart of many UI-based platforms (and our digital economy at large), these benchmarks stand as a good indicator of average uptimes and latencies in the industry.

    For example, at the time of writing, API.Expert’s Enterprise APIs collection ranked Microsoft Office365 and Pivotal Tracker at the top, both with a 100.00% pass rate and a 220 ms and 248 ms latency, respectively. On the other end of the spectrum, Docusign is at 99.93% with an 877 ms latency and Box is at 99.99% with 414 ms latency.

    SLIs, SLAs and SLOs—Oh My!

    Although it may sound good to an unpracticed ear, an SLA of 99.99% still equates to 52 minutes and 36 seconds of downtime per year. That’s nearly an hour of downtime in which customers are left scratching their heads or, worse, searching for other options. For traumatic health care situations, a loss of connectivity could be a matter of life and death.

    Although creating SLAs and SLOs is important to gauge system health, the reality is that it can be challenging to track and enforce them. “These agreements—generally written by people who aren’t in the tech trenches themselves—often make promises that are difficult for teams to measure,” according to the Atlassian knowledge center.

    In summary, SLIs demonstrate the real behavior of software systems. These metrics inform the creation of SLAs, which must be met to ensure B2B agreements. These SLAs often reference particular service-level objectives (SLOs) that must be met, which usually give more breathing room around SLIs. Lastly, in a digital economy with accelerating digital expectations, it makes sense to monitor internal SLOs and improve baselines over time.

  • Shift Left is Only Part of Secure Software Delivery

    Shift Left is Only Part of Secure Software Delivery

    We’re living in the age of accelerated consumption and delivery. You can get a seemingly infinite selection of products delivered to your door within two days, for free, from thousands of miles away. You can access an endless variety of services online within mere seconds: Movies, music, games, education and even health care. These modern marvels are afforded to us by relatively recent advances in software development, delivery and operations. 

    Among those advances are the adoption of DevOps practices, continuous integration and continuous deployment (CI/CD) pipelines, and automating everything from infrastructure provisioning to testing and quality assurance. These advances enable developers to deliver software faster and think about security earlier in design and development to ship safer software.

    What is Shift Left” and Why Does it Matter?

    “Shift left” is a philosophy for addressing the pitfalls of traditional waterfall-style development. In waterfall, a number of IT teams work over the course of many weeks or months, culminating in a big and beautiful software release. Of course, people make mistakes, forget things, and maybe don’t communicate well with each other. When it turns out that application elements don’t interoperate well, the teams frantically attempt to fix what’s possible and jettison what isn’t, with a very serious deadline staring them in the face. Products inevitably ship late, still somewhat broken, and with security bolted on as an afterthought.

    To shift left means to introduce security process and tooling earlier into the design and development phases. Security should be just as critical as functionality and quality. It’s a great idea because discovering a critical, build-failing vulnerability in a critical dependency after you’ve built dozens of functionalities on top of it hurts a lot more than if it’s found before you build anything at all. Maybe fixing the problem is as simple as using a newer version of a dependency, but now you have to make sure everything you’ve customized still works as intended.

    There are a number of forms of application security testing (AST) that aim to detect code-level issues early in the systems development life cycle (SDLC). Two common types of AST when shifting left are software composition analysis (SCA) and static application security testing (SAST). Put simply: SAST tests the custom code your developers write; SCA tests dependencies you include in code. 

    Assessing the security of modern applications requires both testing types. If you believe shift left means not only finding problems but also fixing them, then developer-friendly tooling is necessary. Exactly what that means can be subjective depending on developer workflows in the organization, but at the very least, developers need self-service, seamless integration into their existing CI/CD toolchains and actionable results. Because most developers aren’t security experts, security findings must prioritize the riskiest problems, point to the source of the issue and provide contextualized fixes, rather than making the developer hunt for them on their own. 

    Augmenting AST With Runtime Intelligence

    One challenge with doing a lot of early testing—especially security testing—is that the more you test, the more findings you discover. Unfortunately, some of the results will be false positives and others may be true positives that pose a relatively low risk. Development teams with a high degree of security expertise must sift through and vet findings to prioritize flaws that are severe and actionable, but such practitioners are in short supply and this type of work is tedious.

    Addressing the pitfalls of security testing isn’t simple, and it involves gathering as much contextual information as possible to begin to reason about the risk associated with each finding, usually expressed by what exploitable code is actually exercised. 

    Reasoning about vulnerability risk is not easy. We try to rank the criticality of issues to decide on an action. We can split the problem into two parts: 

    • The context of the vulnerability itself includes metrics of severity, like the CVSS score, and threat intelligence, like whether exploits are publicly available or attacks are prevalent in the wild. This information is readily available from scanning tools and third-party sources like NVD, MITRE and CISA.
    • The afflicted asset’s environmental context, however, is specific to your application and your infrastructure. Only your organization can really fill this part in. For example, is the impacted application protected by mitigating security controls? Is it exposed to the internet? Does the vulnerable component even get used at all? This is difficult or impossible to know until the application is running in its intended production environment. 

    Shift left is a way forward for modern cybersecurity, but the approach can be vastly enriched by pulling in runtime intelligence. This helps to prioritize what to fix first, removes friction, saves cycles of numerous IT teams and reduces your organization’s vulnerability risk.

    What Happens After Release?

    The whole point of shift left is to release secure software faster, but what happens next? Your flawless, beautiful code is delighting your customers with its stunning feature set and impressive performance. Then, on some idle Friday afternoon, right before what should have been a long holiday weekend, you get hit with a horrendous zero-day that you could never have predicted even if you tried. 

    When that happens, you need to respond by quickly identifying all of the affected workloads running in your environment and prioritizing them for remediation. You may need to take those workloads offline to patch immediately, limit network access to them, or otherwise mitigate the problem if a patch is either unavailable or taking too long to deploy. The point is that in real life, shift left is only one part of a successful security program, and the protective, detective, and remediation activities for your production environments on the right are also critically important to your organization’s safety and success.

    Conclusion

    Shift left alone was never going to solve all security problems, but it does create foundations for reliable, fast and secure software delivery pipelines. Security and development teams alike often suffer from a deluge of noise and few useful signals. What they really need are consistent and prescriptive ways to make sound decisions about risk. Gathering context from multiple sources through multiple layers of the stack, including runtime signals, substantially improves the quality of the information that DevSecOps teams receive from their tools and must act on.

    Effi Goldstein, director of products at Snyk, co-authored this article. Check out Sysdig and Snyk’s 2022 Container Security Trends: Expert Panel Livestream for more information. 

  • How DevSecOps Teams Can Level Up

    How DevSecOps Teams Can Level Up

    In 2019, I wrote a post detailing the traits of DevSecOps—the practice can be defined as the process of security automation in which IT and security are more de-siloed. DevSecOps introduces a more intentional culture wherein security-by-design principles are baked into the software development process early on. All in all, the aim is to have security enable development, not stall IT and slow down the SDLC.

    So, years later, how is DevSecOps doing? Has it achieved this ideal? Well, I recently met with Jeff Williams, CTO and co-founder of Contrast Security, for insights into the state of modern DevSecOps. According to Williams, most large companies still have real problems with application security and software dependency providence is constantly in question. We’ve recently seen this reality rear its ugly head amid exploits in frameworks like Log4j and Spring4Shell.

    Large organizations are likely carrying tens of thousands of vulnerabilities in their backlog. Yet, as consumers, we happily trust software for our critical applications without knowing what lurks behind it. “The industry has a real transparency problem,” said Williams. And as applications are getting more interconnected, they are getting more complicated and they’re getting more critical, Williams added. “These three Cs—connected, complicated and critical—make security harder.” These conditions are culminating in what he called “a perfect storm.”

    6 Ways DevSecOps Teams Should Respond

    So, how should DevSecOps teams respond to the seemingly endless barrage of new vulnerabilities and attacks? Williams shared some general ways teams can increase their security posture.

    1. Practice Security in Sunshine

    It’s easy to point fingers when something goes wrong, especially if it’s a serious vulnerability or attack. Instead, Williams encouraged teams to practice what he calls “security in sunshine.” This is an attitude that gives more transparency to security issues internally. Embracing a culture of blameless retrospectives can ensure employees are comfortable bringing up issues within their team.

    Security in sunshine can be adopted in an external-facing way as well. Williams likened it to how, in product manufacturing, it’s standard practice to share a bill of materials (BOM) with trade partners. We may see similar labeling standards emerge for software in the form of software bills of materials (SBOMs) so that external consumers are better aware of dependencies and potential threats, Williams suggested.

    Cybersecurity awareness certainly takes a communal effort that requires transparent communication. We see this realized daily in bug bounty programs, CVE reports and fixes to open source software. Bringing potential threats into the light of day is necessary to squash vulnerabilities before they are exploited.

    2. Translate High-level Requirements

    Security guidelines issued by bodies such as NIST and ISO are essential to keep in mind. Implementing the concepts these guidelines recommend, such as the principle of least privilege, multifactor authentication and zero-trust architecture, are considered best practices by most security professionals. However, these high-level requirements don’t often translate down to the developer on the ground floor. “The developer needs those requirements translated down four levels to specific technologies they’re working with,” said Williams.

    A programmer needs more realistic advice on how these guidelines affect, say, Spring Boot applications or how they should configure permissions in AWS. According to Williams, teams must interpret these abstract recommendations with more concrete annotations that meet the nuances of the technology stack they’re working in. The same process is required to help developers create projects compliant with data regulations, as it’s difficult to take this high-level advice into practice. Translating these requirements into more readable terms is an excellent way to de-silo security and development teams.

    3. Shift Smart

    In recent years, there’s been a lot of talk about shift left. The idea is that to reduce security threats later on, organizations need a tighter grasp on security earlier in the software development life cycle. Shifting security left is often enabled with tools that hold code accountable for potential threats using automated analysis.

    However, Williams sees this as an area where organizations need to be careful. Not all security tools are developer-friendly and might introduce inefficiencies at scale. Instead of shifting left, he advocates for “shifting smart” to introduce security at junctures where it’s most efficient. “You don’t want to shift all security left—you want to shift right too,” explained Williams. “Spread it out over the whole life cycle.”

    4. Avoid Added Steps

    There’s more than one way to bake a cake. Similarly, there’s more than one way to cook up a great software application. As such, most organizations are dealing with multiple tools, making it harder to apply security consistently across all stacks.

    Security should be catered to the specific tooling and processes being used, Williams explained. But that requires answer certain questions like where is a software development team in their journey? Are they waterfall or Agile? How does each CI/CD pipeline behave?

    Obviously, there are many unique factors to consider. Ideally, tooling should be flexible enough to attach itself to existing infrastructure, Williams said, instead of adding additional steps to an already sprawling tooling ecosystem.

    5. Take Security Seriously

    And, of course, there’s the cultural element. “It’s 2022, and companies still don’t take security seriously—they need to change,” said Williams. “It doesn’t matter how they get there—that they get there matters most.”

    Admittedly, cultural change is a slow evolution and the best way to advance will be to add practices and technologies progressively over time. Thus, Williams recommended iteratively inserting pieces, measuring outcomes and proving value along each step of the journey.

    6. Update Outdated Tools

    WhiteHat Security found the average time it took to fix critical vulnerabilities in the spring of 2021 was 205 days. But such a long timeline is at odds with the pace of new threats and the need to patch them quickly.

    The industry is changing the way they do AppSec, said Williams. Traditional DevSecOps security tools, he said, such as static analysis tools, dynamic analysis tools and web application firewalls, are outdated and less accurate compared to newer technologies like interactive application security testing (IAST) and runtime application self protection (RASP). Accuracy, speed and scalability will be important characteristics for security automation tools that don’t require additional human intervention or produce too many false positives.

    DevSecOps Is Still Maturing

    A healthier DevSecOps practice aims to decrease the “vulnerability escape rate,” as Williams called it. Hopefully, by providing instant feedback on designs, engineers will learn not to repeat the same mistakes, thus decreasing the number of vulnerabilities they introduce.

    In summary, DevSecOps is still maturing. Looking to the future, a stronger DevSecOps approach will require a more open attitude to mitigate threats. It also requires practical guidance as not all top-down guidelines translate well into the active development environment. Applications will require proper code hygiene, and the software supply chain itself must be protected, too, in addition to conducting active monitoring of production environments.

  • The Importance of Customer Experience Observability

    The Importance of Customer Experience Observability

    Ask anyone to name their favorite brand, and they’ll often respond with minimal hesitation. Prod a little further and the importance of customer experience (CX) is sure to play a major role in their response. In fact, 96% of consumers say CX is a key factor in their choice of loyalty to a brand. This sentiment is even more powerful post-pandemic, with 58% of consumers saying they place more importance on CX when making purchasing decisions than they did pre-pandemic.

    Will the importance of CX only increase? That’s a safe bet. So how does a business get to Apple, Disney or Amazon-level CX? Reliability is a good place to start.

    Reliability—in the context of a digital-first business—is the ability to quickly identify and resolve issues before they reach the customer. Reliability is a critical demand of both consumers and enterprises as they pursue digital transformation, especially cloud migration and automation.

    Achieving reliability may sound rather straightforward, but many factors in DevOps often work against reliability. For instance, many DevOps teams focus solely on technical performance metrics but turn a blind eye to CX metrics like churn rate or net promoter scores (NPS). Some business leaders fix this with advanced AI and machine learning technology, but too often those solutions don’t live up to expectations enough to provide a return on investment (ROI).

    Observability, on the other hand, is an approach that collects and analyzes data on every component of a system, application and infrastructure—from performance to security to accessibility. This information allows DevOps teams to glean insights on the reliability of actions performed within a unique business environment, such as an interactive voice response (IVR) system or a contact center.

    Gartner defines observability as the evolution of monitoring into a process that offers insights to speed innovation and enhance CX. To establish digital observability, DevOps teams should consider the following components.

    Enable Automated Testing of Digital Technology Functions

    Every day, companies are losing revenue due to a lack of customer experience observability. Forrester reported that more than $1 billion in potential revenue is being left up for grabs. This is largely due to poor comprehensive customer experience technology investment decisions. As DevOps teams work to deliver new CX innovations—like personalized VR shopping experiences or advanced AI-based chat support functions­­—they do their best to foresee potential flaws or bugs. However, flaws will inevitably creep in. That’s why consistent observability is crucial. Observability helps DevOps practitioners see these issues quickly and gives them optimum time to respond before it becomes a costly threat to customer experience.

    To provide this level of observability, data must be available, accurate and analyzed in real-time. This requires automated solutions because the faster a data set can be analyzed, the more value it will deliver. Automated testing tools work by generating thousands of synthetic omnichannel interactions to test the customer journey from the outside-in—from the network through IVRs to digital apps and routing systems, all the way to agents at their desktops. Automated testing of elements such as connectivity, responsiveness, quality and functionality can help DevOps teams ensure quality is achieved throughout the entire CX development life cycle.

    Determine How Test Data Will be Used to Improve Reliability

    Detecting issues early also requires precision and intentionality that answers questions like: What data will be collected? Who will own and examine the data? Why does that data matter to our business? Being able to analyze, organize, manipulate and share test data helps DevOps teams have greater ownership and oversight over information that’s constantly coming in.

    DevOps organizations benefit from using a platform that centralizes all voice call test data for the entire team so that nothing is missed, and the data can cover a wide array of use cases. Typical test datasets might include information on factors such as customer persona labels (for example, Gold, Silver and Bronze customers or labels by Line-of-Business), order status or payment methods. A centralized monitoring and testing platform allows DevOps teams to create and import comma Separated Values (CSV) files to create a test dataset for a specific IVR and then use it to test the organization’s other IVR systems to save time by not re-creating it manually. It’s also important for internal teams to be able to track who is modifying test data, when it’s being modified and which test cases are using specific datasets.

    Dedicate an Executive Champion of Customer Experience

    Eighty-four percent of businesses that focus on improving CX report an increase in revenue. Executive investment in CX is critical here and considering the ROI, should not be a difficult sell. To go even further, businesses should consider establishing a leadership role that is responsible for proactively addressing CX and reliability.

    For CX digital transformation initiatives to succeed, they must be led by an executive leader who can champion the need to drive cultural change and strategic investments. Appointing an executive to this role will ensure that CX initiatives aren’t siloed from DevOps teams, but also from the rest of the enterprise, including sales, marketing, operations and more.

    Some organizations choose to create an entirely new chief CX officer role so that the leader can give their full attention to CX transformation initiatives, processes and technologies. Others, depending on the company’s organizational structure, may decide to appoint these responsibilities to the current COO, CIO or CMO. Whatever the decision, the digital transformation leader must have broad authority that covers budget, people and processes in order to be effective in their role.

    Focusing on observability within customer experience technology will help organizations improve their reliability as a brand. With greater observability and automated testing capabilities, DevOps teams will be empowered to innovate faster and deliver higher-quality solutions that will improve customer interactions and solidify brand loyalty for years to come.

  • Survey Sees Little Progress on Securing Software Supply Chains

    Survey Sees Little Progress on Securing Software Supply Chains

    A survey of 1,750 IT security decision-makers published today found that, despite a series of high-profile cybersecurity breaches, nearly two-thirds (62%) of respondents have done nothing to secure their software supply chain. A full 64% conceded that an attack against their software development environment could not be stopped. And nearly three-fourths (71%) of respondents admitted their organization suffered a successful software supply chain-related attack that resulted in data loss or compromise of an asset, while 85% acknowledged a software bill of materials would also reduce the risk of compromise to a software supply chain.

    The survey, conducted by the market research firm Vanson Bourne on behalf of CyberArk, a provider of a privileged access management (PAM) platform, also found that 87% of respondents stored secrets in multiple places across DevOps environments, while 80% conceded developers typically have more privileges than necessary for their roles. Only 3% of respondents said their organization has a centralized secrets management platform to manage credentials used by applications.

    Organizations are also struggling to keep pace with the number of digital identities that have access to IT services. The average staff member has access to more than 30 applications and accounts, the survey found. However, 68% also reported non-humans or bots have access to sensitive data and assets, with machine identities now outnumbering human identities by a factor of 45, on average, the survey found. Less than half (48%) of respondents have any type of identity security controls in place for their business-critical applications.

    Even the threat of ransomware doesn’t seem to be having much of an impact. More than 70% of respondents said their organization has experienced, on average, two ransomware attacks in the past year.

    Brandon Traffanstedt, senior director for the global technology office at CyberArk, said it’s apparent organizations are accruing a significant amount of security debt that is not being proactively addressed. In fact, more than two-thirds of respondents (69%) said their organization has prioritized maintaining business operations over ensuring robust cybersecurity in the last 12 months. A full 99% of respondents said their organization had fast-tracked the adoption of at least one business/IT initiative over the last 12 months.

    In general, hybrid working (86%), the introduction of new digital services for customers or citizens (84%) and increased outsourcing (84%) are identified as the activities that are introducing the greatest risks. Specifically, the survey found credential access (40%) was the number one area of risk, followed by defense evasion (31%), execution (31%), initial access (29%) and privilege escalation (27%).

    Real-time monitoring and analysis to audit all privileged session activity; least privilege security/zero-trust principles on infrastructure that run business-critical applications and processes to isolate business-critical applications from internet-connected devices to restrict lateral movement are tied at 54% for the top three security initiatives organizations are planning to implement. The top three strategic zero-trust initiatives are workload security (52%), identity security (50%) and data security (45%), the survey found.

    Ultimately, the only way to address the current level of security debt organizations are incurring is by embedding functionality into DevOps workflows that automatically apply security policies and teaching developers to build more secure applications, said Traffanstedt. The former approach, however, may have a bigger impact more quickly, given the current level of cybersecurity expertise that currently exists in the developer community.

  • Atlassian Expands DevOps Tools Portfolio to Improve Collaboration

    Atlassian Expands DevOps Tools Portfolio to Improve Collaboration

    Atlassian has added an extensible catalog for tracking software components, dubbed Compass, to its portfolio of DevOps tools along with an Atlassian Data Lake and Atlassian Analytics cloud service that makes it simpler to aggregate and query data collected from the company’s portfolio of tools.

    In addition, Atlassian is making its Atlas collaboration framework—formerly known as Team Central—formally available in beta. That framework, in effect, provides an overlay through which different collaboration tools adopted by various DevOps teams can be more easily integrated.

    Compass provides DevOps teams with the ability to map all the components they use to assemble their software as well as the teams that own them. DevOps teams can access shared components and documentation along with scorecards to allow them to measure and evaluate their architecture based on the baselines, security or compliance requirements they might be required to meet. It can be extended to other applications via an integrated Apps engine using Forge, the existing Atlassian cloud development environment.

    Tiffany To, head of product for Agile and DevOps at Atlassian, said Compass is designed for DevOps teams that are typically trying to manage 50 or more microservices. It is designed to be deployed alongside the Jira project management software that is widely used by software development teams to manage multiple projects.

    Atlassian Analytics, meanwhile, is based on a visualization and analytics platform the company gained last year with the acquisition of Chartio. Initially, the Atlassian Data Lake will include data from Jira Software and Jira Service Management tools with support for additional Atlassian platforms planned.

    Collectively, these tools are part of an ongoing Atlassian effort to make it simpler to integrate multiple DevOps teams, said To. Many of those teams prefer to maintain autonomy over the tools they select. The challenge that creates is organizations need some type of overlay through which they can collaborate and share best practices, she said.

    A survey of 2,000 developers conducted by Atlassian found half of the respondents exercise strong autonomy over the tools they use, with more control over tool selection gained as developers become more experienced. The same survey also found that 65% of developers felt they should be responsible for more of the software product life cycle than they currently are.

    It’s apparent that most organizations building software are trying to strike a balance between developer autonomy and centralized control. Developers are expensive to hire and retain, so there is a natural tendency to make available the tools they prefer. That, however, can lead to a level of tool sprawl that makes it difficult to determine the overall state of application development and deployment within an organization.

    Regardless of the approach, the need to remove as much friction as possible from DevOps workflows is clear, especially as the number of simultaneous application development projects continues to multiply. The challenge and the opportunity, of course, is achieving that goal while keeping developers happy.

  • Radware Embraces APIs to Improve AppSec Across Multiple Clouds

    Radware Embraces APIs to Improve AppSec Across Multiple Clouds

    Radware this week launched an application programming interface (API) approach to securing multiple clouds designed from the ground up to be an extension of a DevSecOps workflow.

    Eyal Arazi, a senior product marketing manager in Radware’s security group, said that Radware SecurePath makes it possible to invoke any of the company’s cloud security offerings via an API. That eliminates the need to depend on inline security platforms that require separate consoles to be managed.

    Instead, the out-of-path approach enabled by Radware makes it simpler to consolidate the management of security across multiple clouds, he said. The API approach allows application requests to go directly from the client to the application server and reduces complexity and latency, eliminates routing changes and increases overall availability, noted Arazi.

    DevOps teams can now access the entire Radware cloud security portfolio, including the Radware web application firewall (WAF), API protection tools and a service that thwarts distributed denial-of-service (DDoS) attacks via a consistent set of APIs, said Arazi. Radware will continue to make those offerings available to be deployed inline or out-of-path as IT teams see fit, he added.

    Every time an organization deploys workloads on another cloud platform, an already complex security challenge becomes more complicated. Today, most of the responsibility for securing those clouds lies with cybersecurity teams. However, as DevOps teams gain access to tools and platforms that make it more feasible for developers and DevOps teams to programmatically manage security, more of the responsibility for it is shifting further left.

    Part of the benefit of that approach is the elimination of the need to deploy and manage firewalls on virtual machines or the need to reroute traffic via content delivery networks (CDNs) to inspect traffic, noted Arazi. It also enables the Radware security offerings to piggyback on the certificates that are already being employed in cloud platforms, he added.

    In the longer term, the goal is to reduce—or outright eliminate—the vulnerabilities that now routinely make it into production applications. Many of the cloud security issues that organizations regularly face can be traced back to misconfiguration mistakes made by developers. It’s not that a developer deliberately sets out to build and deploy vulnerable applications. Rather, they simply lack the expertise required to make sure that, for example, ports are not left open. In the absence of that expertise, more tools must be embedded within DevOps workflows to better ensure application security. After all, it may be years before most developers attain any meaningful cybersecurity proficiency.

    In the meantime, closer collaboration between DevOps and cybersecurity professionals is required. There are simply not enough cybersecurity professionals available to participate in every phase of an application development project. DevOps teams need to be able to identify and remediate issues as early as possible. Otherwise, a cybersecurity issue that gets discovered at the last minute is likely to prevent a workload from being deployed in a production environment.

    In the absence of any additional effort, it’s really only a matter of time before cybercriminals become more adept at compromising cloud application environments.

  • ACCELQ Further Automates Testing of Low-Code, No-Code Apps

    ACCELQ Further Automates Testing of Low-Code, No-Code Apps

    ACCELQ today unveiled the cloud-based ACCELQ Live test automation platform that is continuously integrated with a wide range of low-code and no-code application development and deployment platforms.

    ACCELQ CEO Mahendra Alladi said the goal is to make it simpler to run complex tests across a multi-cloud computing environment.

    Usage of low-code and no-code tools has greatly expanded since the start of the COVID-19 pandemic. Many organizations are now relying on these tools to accelerate a wide range of digital business transformation initiatives. The challenge they encounter is that many of these processes depend on multiple applications that have lots of interdependencies across which it is difficult to conduct tests, noted Alladi.

    The ACCELQ Live platform reduces testing complexity by automatically updating itself as, for example, Salesforce or ServiceNow platforms are updated. It also provides access to pre-built codeless automation assets modeled on business processes via a live link. The company is also moving toward creating a marketplace where software vendors and service providers can build and deploy pre-built testing assets, as well.

    Gartner predicts the adoption of low-code and no-code technologies will nearly triple by 2025. Testing those applications creates a major challenge as the pace of application development increases. The only way organizations will be able to keep pace is by embracing test automation platforms infused with artificial intelligence (AI) capabilities, said Alladi. In effect, ACCELQ’s ACCELQ Live represents an effort to democratize the testing of cloud and enterprise apps, he added.

    As organizations increasingly appreciate their dependence on software, the way tests are being conducted is rapidly evolving. In addition to dedicated testing teams, developers and application owners are becoming more involved as responsibility for testing applications continues to shift further left. The challenge organizations face is the volume of applications that are simultaneously being constructed has significantly increased. Platforms that automate many lower-level testing functions are gaining traction as a means to enable humans to focus more of their time and energy on testing more complex functionality. The goal now should be to first rely on test automation platforms as much as possible and then employ humans to fill in the gaps as necessary, said Alladi.

    It may be a while before most organizations achieve that level of test automation. However, with each passing day, it’s apparent that AI will play a larger role in application testing. The issue that many DevOps teams are now working through is how to incorporate test automation platforms within the context of a larger workflow.

    In the meantime, the rate at which application testers become burned out should decline as more routine errors are uncovered by machines. It’s not likely AI will eliminate the need for dedicated testing teams any time soon, but as more rote tasks become automated there is going to be more time to focus on enhancing overall quality at a time when application environments have not only become much more distributed but also a lot more complex.