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.

  • JFrog Adds Module to Better Secure Software Supply Chains

    JFrog Adds Module to Better Secure Software Supply Chains

    JFrog today added a JFrog Advanced Security module to its Artifactory repository that enables DevOps teams to scan both binaries and source code for vulnerabilities and misconfigurations.

    Stephen Chin, vice president of developer relations for JFrog, said that approach will enable DevOps team to ensure applications are secure before they are deployed in a production environment.

    In addition to discovering vulnerabilities, the JFrog Advanced Security module also detects exposed secrets such as passwords, access tokens and private keys, said Chin. Leveraging existing scanning capabilities provided via the JFrog Xray software composition analysis tool, it can also be used to inspect the file used to provision infrastructure-as-code, he added.

    Most importantly, it provides development teams with the context needed to determine which components of an application are using containers that encapsulate code that is actually exploitable, noted Chin.

    One of the major issues DevOps teams encounter today is that they are often presented with a long list of vulnerabilities by cybersecurity teams—many of which don’t meaningfully impact applications that are not exposed to the Internet. DevOps teams then need to manually report why any given vulnerability doesn’t need to be remediated. The JFrog Advanced Security module helps automate that process, said Chin.

    In general, JFrog continues to pursue a binary-first approach to securing software supply chains, said Chin. While it’s important to address vulnerabilities in source code whenever possible, it is application binaries running in a production environment that cybercriminals are going to exploit, he noted.

    Cybercriminals have, in effect, opened a new front in their efforts to compromise IT environments by injecting malware into software components before they are deployed in a production environment. The hope is that, once deployed in those environments, malware can be activated at some later date. As a result, DevOps teams are now being required to improve cybersecurity hygiene across their software development processes, said Chin.

    It’s not clear at what rate organizations are embracing DevSecOps best practices to achieve that goal, but in the wake of an executive order issued by the Biden administration that requires federal agencies to better secure their software supply chains, the expectation is that more enterprise IT organizations will follow suit. The challenge is finding a way to build and deploy more secure applications without negatively impacting the rate at which they are built and deployed. Earlier this year, JFrog launched the open source Pyrsia project that employs blockchain technology to ensure open source software packages are not compromised by vulnerabilities and malicious code.

    In the longer term, it’s only a matter of time before the historic divide that has existed between DevOps teams and cybersecurity professionals starts to narrow as applications become more secure. The biggest immediate challenge is that many of the applications deployed in production environments already have known vulnerabilities. In the months ahead, many DevOps teams will be asked to assess the severity of those vulnerabilities as part of ongoing efforts to improve application security. Those patching efforts will undoubtedly have a significant impact on the amount of time available to write the code needed to build new applications or update existing ones with new capabilities.

    One way or another, however, the amount of technical security debt that has been allowed to build over the last several decades needs to be addressed.

  • DevOps Principles, Implementations and Culture

    DevOps Principles, Implementations and Culture

    When organizations begin using DevOps for application development, many only reference DevOps as part of their infrastructure and select a subset of DevOps before understanding the cultural and process changes needed for success. Instead, organizations must first determine which ‘Ops’ approach best promotes a DevOps mindset and integrate their workflows into their culture. In doing so, these organizations will better align their development and operations teams on common goals and protocols.

    There are many variations and subgenres of DevOps. However, it’s important organizations understand the ‘Ops’ choices available and choose the one that’s right for them.

    Principles Vs. Implementation Differences

    General DevOps and its subgenres can be split into two groups. The first and “purest” are the principles that these terms focus on unifying two or more industries with operations.

    The second type is those that focus on an implementation type.

    Principle Types

    DevOps: Improving Technical Processes and Culture

    DevOps is the overarching umbrella term for operations that combine Agile development concepts with IT operations and fast-tracks the development and deployment of applications in cloud environments. While there are different subgenres of DevOps, each subgenre is a different application of DevOps methodology, all geared toward making development more agile, stable and efficient. Because DevOps shortens the development life cycle by a significant margin, this streamlined approach to application development is quite popular.

    DevSecOps: Adding Security Checks

    DevSecOps bakes additional security measures into the workflow. Where DevOps typically has security checks at the end of a cycle, IT pros that leverage DevSecOps integrate security early and often in their DevOps journeys. With DevSecOps, collaboration between developers, security specialists and ops is crucial to maintaining agility and delivery speed, but the extra layers of security can slow processes down. DevSecOps leverages fast testing and robust pipelines to favor better code integrity. This method can be beneficial if an organization needs to elevate security during development.

    NoOps: Reducing In-House Teams for Operations

    NoOps is the lofty vision that DevOps is so automated it doesn’t require in-house expertise, meaning no manual intervention is required in processes. NoOps differs from DevOps because there is less focus on Agile and process management. This process assumes that developers do not need to know how to use the automated tools and uses continuous integration techniques to allow developers to focus only on application development.

    Though NoOps speeds up the deployment processes, if used by itself, NoOps lacks open communication and team management. Successful implementation of NoOps is only achievable if an organization does not have lofty technical goals or if its development team is small but strong and able to handle development and operations.

    GitOps: Using Git to Automate

    GitOps has been gaining traction in the development industry over the past two years because of its use of Git to automate continuous delivery pipelines. GitOps is a robust and manageable form of operations because it uses Git as the single source of truth for operations. In addition, due to developers’ familiarity with Git and pull requests, there is no complicated tool to learn, and changes to existing workflows are often unnecessary.

    The GitOps method can also boast that it is backed by some of the market’s most innovative cloud services, thus automating the process of building an update, testing for errors, reviewing code and pushing the update to production. Because Git is the only source of truth with GitOps, it is vital to effectively fortify the Git repository to avoid needless commits or pull requests.

    CloudOps: Implementing Cloud-Native Features

    CloudOps attempts to take more advantage of cloud-native features offered by modern service providers. Since CloudOps focuses on distributed development and deployment, there is no single point of failure, making the whole cloud environment more reliable. In addition, certain parts of the workflow in this type of operation can go stateless, making it cost-efficient as organizations only pay for the resources they actually use. Though CloudOps can be time and cost-efficient, organizations must get the configuration right for the approach to be beneficial, which could mean added complications to configuring CI/CD pipelines.

    CIOps: Requiring CI Operators for Configuration

    Continuous integration Ops (CIOps) is the latest iteration of DevOps, requiring CI operators to configure the infrastructure needed to support new code before deployment. The manual inputs necessary to ensure CI jobs’ correct configuration and deployment location bring advantages and disadvantages. Control over infrastructure allows two deployments to have different infrastructure configurations. The major disadvantages are the required manual intervention leaves room for error and the need to link an organization’s CI tool to its API can pose security risks.

    CIOps is better-suited for smaller development environments where automation is an inconvenience. While CIOps gives developers flexibility in configuring cloud infrastructures, the approach takes time and effort to run smoothly.

    ITOps: Automating IT Management Pipelines

    IT is loosely defined as the management of end user or employee systems. They are the systems that are required to run a core business. The fundamental difference is that there is little to no development. If your business doesn’t require a software engineering team and can function solely on prebuilt applications, then ITOps is for you.

    ITOps is in charge of delivering and maintaining services, applications and the underlying technologies necessary to run a business, covering jobs like system administrator and network administrator. ITOps focuses on updating laptops and office networks in addition to highly-tested commercial software and solutions for constructing the infrastructure, making updating infrastructure components more complicated. When using ITOps, an organization’s CIO will focus on managing the system via automation. 

    Choosing the Best Op for an Organization

    Choosing between the variations of DevOps is a matter of finding an approach that works best for the kind of apps the organization is developing and the cloud infrastructure they use. Though all of the above Ops strategies are based on unique ideas, they tend to focus on the technical side. Contrarily, DevOps stands out for its ability to comprehensively improve workflows and streamline technical processes while fostering a culture of innovation and collaboration in an organization.

  • Implementing Data-Driven DevSecOps

    Implementing Data-Driven DevSecOps

    Right now, the way DevSecOps is typically implemented doesn’t fit with the rapid and agile DevOps CI/CD pipeline at all. It’s like applying 19th-century firefighting methods to a modern forest fire.

    Back then, firefighters employed a “bucket brigade,” where they would form a queue and pass buckets from one hand to another to put out a blaze. No doubt, it’s a lot of work, but much of the effort is wasted. Water inevitably spills out of the buckets as they are handed from one person to the next and by the time the bucket is emptied into the fire, half the water is gone. And not only is so much effort wasted, it’s far too slow and ineffectual to combat the kind of wildfires we face today.

    Likewise, the largely manual methods of current DevSecOps initiatives are ineffectual in fighting the fires of digital threats and cyberattacks modern mobile apps face. Like a modern megafire, these threats and attacks are growing and changing every second, seeking new vectors to spark new attacks elsewhere. Traditional DevSecOps tools like code scanning and penetration testing identify vulnerabilities and then the security teams start the manual “bucket brigade” to add as much protection as they can against them before the app has to be released. But neither the threats nor the CI/CD process has paused. New features have been added that have created new vulnerabilities, and the threat landscape has evolved. It’s inefficient because pentesting can’t provide the kind of real-time data about attacks and threats that developers need to provide protection against current threats. The result is the release of vulnerable mobile apps. 

    A Data-Driven Process

    In business, the C-suite is working hard to transform their companies into data-driven organizations where decisions are made not on the basis of gut feelings or expert opinion, but rather on analysis of hard data. That same approach needs to be brought to security implementation for mobile applications.

    Additionally, the implementation of security into a mobile app needs to be automated. With so much of the CI/CD process already automated, security cannot lag behind.

    These two elements combined create data-driven DevSecOps. In this method, the development and security teams have a system of record that provides real-time cyberattack and cyberthreat information about apps in the field, which drives decisions the team makes about the protections that are most urgent and that must be included in the next build. 

    It’s now well within the realm of possibility for mobile app developers to gather near-real-time information on exactly the kinds of threats and vulnerabilities that their mobile apps are facing in the field. When combined with location, network and other kinds of data, developers can gain a granular understanding not only of the most common threats their apps experience, but also which threats are most prevalent in specific geographic regions. They can also proactively identify the rapidly mounting threats that will become an enormous problem in the near future.

    With this data in hand, development teams can make informed decisions about which protections they should prioritize in the next build to make the best use of their time and resources to provide maximum protection to their end users. 

    The Need for Automation

    But having data isn’t enough. Development teams need the ability to act quickly on the insights provided, and manual implementation methods are too slow and cumbersome to keep up with the rapidly changing threat landscape for mobile apps. Once the decision is made, a system must also exist to automate the incorporation of mobile app security, anti-fraud and anti-cheat protections from within the CI/CD pipeline, so that security implementation runs as smoothly as feature creation.

    The advantages of data-driven DevSecOps are many. First, publishers, developers and security teams can understand exactly what cybercriminals are doing against their own apps with real users. With this data and the wealth of other data that organizations can collect from their apps, they can determine which threats are the most pressing, which are rapidly emerging and even how they are distributed among different geographic regions—all of which is extremely valuable information when deciding which protections to build into the next release.

    Finally, once the app is released, teams can use the data they receive about threats and attacks to prove the effectiveness and value of each protection that was included. It’s important information not only for continuous improvement, but also to justify the value of data-driven DevSecOps to management and the C-suite.

    With data-driven DevSecOps, organizations can provide data, transparency and visibility around security to all stakeholders in the CI/CD process—all while making the incorporation of security far more efficient and effective, along with the real-time data to prove it.

  • Google Looks to Secure Software Supply Chains

    Google Looks to Secure Software Supply Chains

    At the Google Cloud Next ’22 conference, Google today launched a managed Software Delivery Shield (SDS) service to enable DevOps team to store, manage and secure the build artifacts in Artifact Registry. At its core, SDS is based on a trust-based policy engine to establish, maintain and verify a chain of trust across the software supply chain.

    In addition, Google has updated its container analysis tool to include vulnerability scanning for Maven and Go containers along with preview support for non-containerized Maven packages.

    The managed Software Delivery Shield service spans a range of Google runtimes environments, including Google Kubernetes Engine (GKE), Cloud Code, Cloud Build, Cloud Deploy, Artifact Registry and Binary Authorization. Cloud Build also now officially supports Supply chain Levels for Software Artifacts (SLSA) Level 3 best practices by default in addition to generating authenticated and non-falsifiable build provenance for both containerized applications and non-containerized Maven and Python packages.

    GKE, in preview now, provides detailed assessments, assigns severity ratings and surfaces the security posture of the clusters and workloads, including insights into operating system vulnerabilities, workload configurations and other actionable insights. Log data can now also be captured while security event information can be routed to, for example, a security information and event management (SIEM) platform.

    The Google Cloud Run serverless platform can also, in preview, display software supply chain security insights such as SLSA build-level compliance, build provenance and vulnerabilities found in running services.

    At the same time, Google is also making available in preview Cloud Workstations, which provide fully managed secure development environments on Google Cloud that can be accessed via a browser. Built-in security capabilities include virtual private cloud (VPC) controls, no local storage of source code, private ingress/egress, forced image updates and identity access management (IAM) policies.

    Finally, the Cloud Code plug-in for integrated development environments (IDEs) now includes a preview of Source Protect to give developers real-time security feedback in the form of vulnerability dependencies and license reporting as they write code.

    Collectively, Google claimed it now provides more than 250 curated packages across Java and Python with verified provenance. It also automatically generates a software bill of materials (SBOM) to create an inventory of all components and dependencies.

    Historically, cloud service providers have been advocating a shared responsibility approach to cloud security that required organizations to not only secure their applications but also the way cloud infrastructure is provisioned. The challenge is developers generally provision cloud infrastructure themselves even though they generally have limited cybersecurity expertise. Too many developers assume the underlying cloud infrastructure is more secure than it actually is.

    Now, cloud service providers are extending the security services they provide at a time when organizations are making security a bigger factor in determining where to build and deploy applications.

    Sunil Putti, vice president and general manager for Google Cloud Platform, said Google is attempting to make cybersecurity invisible to developers in the sense that guardrails will automatically be embedded within the platform.

    The issue is that cloud computing environments are becoming more complex as new classes of cloud-native applications are deployed alongside legacy monolithic applications. Complexity, as always, is the enemy of cybersecurity.

  • 5 Ways to Transform DataOps With Human-in-the-Loop Automation

    5 Ways to Transform DataOps With Human-in-the-Loop Automation

    We are in the middle of a data renaissance. Today, it’s not just about data instrumentation but also learning how to make DataOps a real business advantage for the entire organization. Data has become an inextricable part of products, used to enhance the quality of user experiences. Reliable access to data and the integrity of that data is imperative to drive innovation and business success.

    But just like any process, problems will arise. There will be pipelines that break or data that isn’t instrumented properly. The question then becomes, how can teams more quickly identify problems and continually improve? How can the journey toward data integrity become one of iteration and improvement?

    DataOps teams are by no means strangers to automation—automated CI/CD pipelines and infrastructure-as-code (IaC) are a huge part of their skill set. But there are some components of automation that are less pervasive throughout DataOps, ones that can help promote data integrity and encourage a culture of improvement. 

    It all starts with a different approach to automation—a human-in-the-loop (HITL) approach. Human-in-the-loop automation enables parts of a process to be fully automated while enabling humans to step in at critical points to take action, make decisions and decide the path forward.

    Here are five ways to use human-in-the-loop automation to drive continuous improvement and achieve optimal data integrity.

    Create Better, Earlier Interruption of Problems

    As is life, inevitably things break, issues arise and teams need to step in to remediate. The goal should be to enable better interruption of these problems when they do occur—identifying issues earlier and bringing the right stakeholders together more easily and swiftly.

    HITL automation can help teams not just identify issues earlier but kickstart the incident response and coordinate across teams and stakeholders. Ideally, automated workflows can be triggered from an incoming signal; for instance, from an observability tool like DataDog or BigPanda. An incident response could be started automatically, triggering further automation—like creating tickets, starting a Zoom meeting, creating a Slack channel and bringing together the right team members. 

    By instantly bringing the right people together, the team can investigate collaboratively and more quickly understand the state of the issue. HITL automation should then enable teams to run further scripts to take action and remediate as needed.

    Bake Improvement Into the Process Through Self-Documenting Workflow

    Many companies today are asking, “How do we make sure that we have that full integrated loop, down to the collection point?” Communication between teams is critical to this endeavor. But even before teams can collaborate on improvements, they need to understand the current state of their data so that if, for instance, a team finds that a report isn’t providing what’s needed, there’s a really clean way to get that communication back to the DataOps team to improve the instrumentation in the first place.

    HITL automation can bake improvement into DataOps workflows by automatically documenting every human and machine action throughout a process. Because it’s connected through APIs to all a team’s tools and services, a self-documenting workflow slurps up every action and creates an audit trail. This audit trail is the basis by which teams can more accurately understand not just the integrity of their data, but also how teams are implementing and running processes.

    Bring Human Data to the Forefront of Improvement

    DataOps teams play a big role in making sure the right data is being collected. However, a lot of people are still using systems that are very manual. They may have a good understanding of their log and monitoring data but still don’t have a good sense of the human data around their organization—what processes and workflows people are running.

    Understanding how humans run processes is just as important as understanding technology problems. The self-documenting workflow described above should include documentation of human data, from manually-run scripts to Slack or Teams conversations and, ideally, even auto-update tickets so even maintaining a system of record becomes less manual. Only by looking at the full picture—of human and machine data together—can teams find areas of improvement in their automation, communication and workflows.

    Take an Incremental Approach

    Don’t let “perfect” be the enemy of “done”. Every great transformation I’ve seen started with a small team, a great mandate, and strong support from the executive team. Adding tons of new technology and hiring more people may not be the silver bullet teams need.

    Instead, teams should look at the expertise they have in-house first—the people, technology and processes. Then, begin by taking an incremental approach. HITL promotes incremental, approachable automation by enabling teams to first codify institutional knowledge, analyze, learn and then begin to automate pieces in small batches.

    Diving head-first into a fully automated approach can leave teams in a worse state than nothing at all. Automation is a journey—we learn by doing, by recording human and machine data and then, using insights as our guide, begin to find real value in small doses of automation. These small steps can make a huge impact and, over time, add up to substantial business value.

    Buy for Industry Standards and Build for the Gaps

    As I mentioned above, teams should first start by evaluating their current resources. What skill sets and technology do they already have and how can they use those resources to achieve their data goals? At the same time, many teams starting their automation journey face challenges—lack of development resources, scripts that live on one person’s machine, difficulty bringing all the human and machine data together into a recorded timeline.

    To help data teams effectively and reliably implement HITL automation, investment into an off-the-shelf platform can help bridge the gaps teams and organizations have. Platforms should enable automation through low-code interfaces while providing code-level customization. This combination enables teams to buy for industry standards while building for the gaps—not managing the platform means development resources can be focused on expanding and improving automation.

    Platforms should enable teams to easily connect to APIs and adapt to custom APIs. The continuous change of DevOps processes and tooling coexist with rapidly changing APIs. Therefore, the most promising automation platforms must manage the complexity of APIs, enabling users to focus on the intent, not the mechanics of custom APIs. Automation technologies should seamlessly handle identity, authentication, pagination and caching. 

    Find Leverage With HITL Automation and Drive Business Impact

    As data becomes increasingly ingrained in product life cycles and user experience, automation holds the key to faster innovation, product quality and enhanced reliability. Creating a culture of continuous improvement and implementing technology like HITL automation that promotes data integrity throughout the product life cycle is where I’ve seen the greatest leverage for organizations. 

    To hear more about cloud-native topics, join the Cloud Native Computing Foundation and the cloud-native community at KubeCon+CloudNativeCon North America 2022 – October 24-28, 2022.

  • Allstacks Adds Alert Capability to VSM Platform

    Allstacks Adds Alert Capability to VSM Platform

    Allstacks has added an alert capability to its software-as-a-service (SaaS) value stream management platform that automatically notifies DevOps teams when software project goals and deadlines are likely to be missed.

    The core Allstacks platform employs machine learning algorithms and artificial intelligence (AI) models to keep track of pull requests, commits and card changes via a set of dashboards that are designed to be accessible to anyone in an organization.

    The Allstacks Alerts capability makes it possible to notify those stakeholders via email or Slack any time a specific indicator, such as a pull request, has been open for four days, which would suggest risks of delays have increased. Support for Microsoft Teams will be added early next year.

    Adam Dahlgren, senior vice president of product for Allstacks, said the goal is to leverage the advanced analytics built into the platform to surface thoughtful observability insights versus simply firing off a series of generic alerts that lack any context.

    Value stream management (VSM) platforms such as Allstacks automatically take technical metrics collected via DevOps tools and correlate them to key performance indicators (KPIs) defined by business leaders. The concept of value stream management traces its lineage back to lean manufacturing methods, which called for each step of a manufacturing process to be continuously measured. As software development has evolved from being a craft to a highly-automated process using DevOps best practices, an appreciation for the value of monitoring the impact of missed software development deadlines on the business has grown as organizations realize how dependent they are on software.

    In fact, many organizations are discovering there is a clear disconnect between their business goals and software development processes. Business leaders are especially anxious to understand how a software development project delay might impact future revenue projections at a time when economic conditions are the most uncertain they’ve been in recent memory.

    VSM platforms also make it possible to track KPIs spanning multiple software development projects; the hope is that doing so will make it easier to see where resources should be reassigned as various bottlenecks are encountered. In the long term, Allstacks is also working toward adding scenario planning tools to make it easier for IT and business leaders to model “what-if” scenarios, added Dahlgren.

    It’s not clear how much organizations are willing to invest in VSM platforms, but the need for them is becoming more acute. The challenge many organizations still face is making sure they have the tools in place to collect the appropriate technical metrics. A SaaS-based platform should make it simpler to achieve that goal and to apply algorithms to what can quickly become a large corpus of data.

    Of course, it’s still early days as far as the adoption of VSM platforms are concerned. But there’s no doubt the divide between application development teams and the rest of the business is continuing to narrow. Less clear is to what degree that increased visibility will lead to a higher degree of empathy between dev teams and the business.

  • Endor Labs Applies Graph Analysis to Secure Software Supply Chains

    Endor Labs Applies Graph Analysis to Secure Software Supply Chains

    Endor Labs exited stealth mode today to launch a platform that applies graph analysis to identify the depth of dependencies that exist within an application.

    Fresh from raising $25 million in funding, Endor Labs CEO Varun Badhwar said the Dependency Lifecycle Management Platform makes it simpler for organizations to manage dependencies within applications that can involve tens of thousands of components.

    Existing software composition analysis (SCA) tools are not able to as accurately identify the dependencies between software components because they generate too many false positives, he added.

    To address that problem, the Dependency Lifecycle Management Platform provides the equivalent of a credit risk score for each component employed with an application environment, said Badhwar.

    Designed to run out-of-band within a continuous integration process, the Dependency Lifecycle Management Platform is currently being made available via a private beta program.

    On average, bout 80% of an application is made up of open source components that developers downloaded from a repository. The challenge is that many of those components have known vulnerabilities. The Dependency Lifecycle Management Platform makes it simpler to both identify those vulnerabilities during the build process and find components that might be impacted by a newly discovered zero-day vulnerability, said Badhwar.

    Overall, the Dependency Lifecycle Management Platform improves the productivity of both application development and cybersecurity teams by streamlining vulnerability management, he added.

    Having a full understanding of their dependency graph also lets customers generate and analyze accurate software bills of materials (SBOMs) as applications are dynamically updated, noted Badhwar.

    In the wake of a series of high-profile breaches, there has been increased focus on software supply chains. The challenge is most developers don’t have a lot of cybersecurity expertise and, even when provided with tools to identify vulnerabilities, there are simply too many alerts generated. In the absence of any context, most of those alerts simply wind up being ignored. In the meantime, the rate at which new applications are being deployed and updated isn’t slowing down, especially as more organizations embrace cloud-native applications that make it easier to rip and replace software components.

    It’s going to take years for organizations to implement DevSecOps best practices to teach developers how to build more secure applications, but that journey needs to begin with tools that make it simpler for developers to address issues before applications are deployed. The best way to combat application vulnerabilities is to make sure they don’t manifest themselves in code in the first place. Based on the number of vulnerabilities that continue to find their way into application environments, it’s apparent that the current processes being used to build applications are fundamentally broken.

    At this juncture, it will take years to fix the application development and deployment process, but as more secure applications eventually replace millions of insecure applications the overall security posture of organizations will steadily improve. The issue now is finding ways to achieve that goal before another known vulnerability leads to another major security crisis.

  • Forget Automation: Why IT Should Take UX Cues From Fine Dining

    Forget Automation: Why IT Should Take UX Cues From Fine Dining

    As a college student, I worked at a five-star Italian restaurant where I learned the discipline and practice of customer service. The general manager knew exactly which corner to stand in to get a view of every single table during service. They would gauge diners’ experience according to how they were interacting, their microsignals, how much food was left on their plate and the way they glanced around the restaurant. What does this intense attention to detail and individual customer experience have to do with running a service-oriented technology business? Everything.

    The tech industry is notorious for automating processes at the expense of personalization, and that aversion can extend to building the relationships necessary to produce a successful end product. Understandably, some companies and their developers prefer to keep relationships with their clients strictly functional because these connections are messy, people are unpredictable and nothing ever goes completely according to plan. It’s a dance we have to do over and again with every new client and project. 

    For those of us who wish to function as service-oriented tech companies, keeping on top of client and customer experiences requires us to stay attentive and listen with active care. Just like the veteran restaurant manager, we have to constantly scan our environment for cues of satisfaction and dissatisfaction.

    Service is More Than an End Product

    Before opening every night, the general manager would make staff hold long pieces of string to measure the angles and distance between tables to ensure they were straight and the edges perfectly aligned. Then, after telling staff the evening specials, he would randomly quiz them about the menu. What color is a fava bean? 

    Seeing the value of such old-school standards left a deep impression and helped me embed attention to detail as a foundational practice across the board, from designing good UX to cultivating relationships. Creating a desirable environment is about successfully orchestrating a million tiny details and always looking for tweaks to make the customer experience better. 

    That seemingly omniscient Italian from my earliest experience in the restaurant industry also taught me that being empathic goes hand-in-hand with the hard-nosed realities of running a service-oriented business. They showed me how to take care of people, how to make them feel good and how to read body language. 

    It might be easy to stereotype tech companies as impersonal dispensers of products (and their developers as cogs in the machinery), but we don’t want to just take orders. Our job is to become strategic partners from the ground up for long-term success, and that requires constant care and continual adaptation. 

    Mapping the Client Experience

    We must be willing to redesign how we work with customers and end users over and over again—it’s always changing because expectations are always changing, and market norms are always changing. The moment that we stop trying to get better through small incremental improvements is the moment we stop being service-oriented.

    In the same way that a restaurant has a sequence of service that maps a diner’s journey from the moment they enter the door, we can architect a customer experience from every touchpoint. 

    In the sales process, it’s valuable to layer in different people to create more relationship touchpoints throughout an organization, so, in our case, a new client meets a member of our operations team and then somebody from our engineering team in order to ensure that they feel fully supported. Then, we set expectations in terms of communication as part of a scripted onboarding experience. In our review meetings, we seek feedback to determine whether we have under-delivered and course correct if necessary. 

    The other thing I learned from that Italian restaurant is that no mistake is irredeemable. It doesn’t really matter if you get it right or wrong the first time, it is how you respond when the unexpected happens that matters. Turning a situation around after making a horrible mistake—even sending out a cold steak—can breed even more loyal customers because it demonstrates that you really care.

    The Creative Heart of Service

    Despite the image of tech as cold and distant, it’s important to recognize that coding and development itself is creative and we should seek to nurture a healthy environment so that people can perform at their best. To that end, it makes sense to think of your responsibility as running the entire length of the chain, from employees to clients and, finally, to end users. Finding humanity in the work along each link is key to building successful partnerships. 

    In the context of building products, we must be creative to design seamless, curated experiences for end users. There are plenty of apps that sit on someone’s phone unused before ultimately being deleted. The only way to grab the attention of people that share the same interests and problems is by understanding their needs. 

    To that end, we must always be asking our clients: What is the easiest point of entry for the user? Creating a low barrier is a quick win that in and of itself is an onboarding experience and an opportunity to build trust. 

    Equally, what may make one customer happy may not actually have any resonance in the wider market. If customers were only hiring us to write code, we would only be interested in meeting their expectations. The goal is not just to build products, but successful products that establish or reinforce a client’s reputable presence in the marketplace. 

    Adding Value Through Relationships

    When we stand in our metaphorical corner of the room to observe the customer experience, we are consolidating data from products that have millions of users and harvesting insight. We are not interested in quick fixes. Customer service and a focus on the end-user experience means being oriented to what the market wants, not designing in a vacuum. We can then continue to build value over time.

    In the restaurant business, the little surprise at the end of dinner adds value because it is unexpected. A complimentary after-dinner liqueur with a pithy origin story is a point of detail at its finest. Creating a richer, fuller customer experience can set a tech business apart in an exploding marketplace. For my old mentors, paying attention to every nuance from the beginning to the end is what defines five-star service.

  • Protecting CI/CD Pipelines to Secure the Software Supply Chain

    Protecting CI/CD Pipelines to Secure the Software Supply Chain

    Cloud-native applications have become increasingly complex. Composed of an infrastructure stack of mash-up code, hundreds of open source and commercial components, services and APIs, today’s software supply chain is fraught with security risks. At the same time, the ability to manage existing application requirements while building innovation and taking on new areas of responsibility like security is stretching DevOps teams beyond their capacity. The concern for the number of connected and exploitable weaknesses across the software supply chain are now requiring organizations to take a proactive approach to protect their continuous integration and continuous delivery (CI/CD) systems, as they have become a target through which attackers infiltrate multiple production systems. But meeting this requirement is no easy feat as it often requires organizations to choose between how much security to enforce in the build cycle while quantifying their risk to build and deploy quickly. 

    A recent survey revealed that nearly all (97%) of an organization’s assets—and security issues—are now in the cloud. And yet, only 29% of an organization’s assets are associated with cloud-specific policies. Addressing this gap requires organizations to have a proactive approach to protect their technology infrastructure, especially securing the artery of their software supply chain: The CI/CD pipeline. By embracing new security and compliance strategies within their governance approach, organizations can better protect their CI/CD pipeline and cloud applications. 

    There is a growing shift toward programmable infrastructure and infrastructure-as-code (IaC) practices to build out infrastructure and manage configuration files. But with this practice comes the increased risk of exposing application credentials, API keys, encryption keys and digital certificates. Tools supporting the CI/CD pipeline have now become the artery of cloud applications, and it’s becoming more challenging to store, transmit and audit data securely. In addition, when CI/CD tools interact with other systems in the DevOps environment, it increases the risk of exposure for configuration files. A compromise in the build system, for example, can be used to get access to production systems that can result in the exposure of sensitive information or the injection of malicious code, corrupting the entire CI/CD pipeline and thus the software supply chain. 

    A recent Unit 42 Cloud Threat report revealed that overly permissive credentials created added risk opportunities in the CI/CD pipeline. The study found that 63% of IaC templates contained misconfigurations and 91% of container images contained high or critical security vulnerabilities. To address this, organizations need to catch security problems in the build process before cloud workloads are provisioned. During the SolarWinds compromise, for instance, attackers used custom malware designed for the company’s build cycle to observe each step. The sophistication of the intrusion in this attack during the software build process is a key lesson for DevOps and DevSecOps professionals and revealed how security needs to be approached. 

    One way to address this is by being able to identify CI pipeline misconfigurations, which can improve security in the software supply chain. Because CI pipelines are configured in the code, the same policy-as-code approach can be used to identify IaC misconfigurations or open source vulnerabilities to surface CI/CD weaknesses. DevOps and developer teams can keep configurations accessible to just a small group who are building for production release. By establishing enforceable permissions to the pipeline, there is better control over who can commit code changes to the repositories, create containers and deploy code to different environments. 

    Strong chains of trust throughout the build cycle are not commonplace today. But as organizations look at ways to strengthen their risk posture by shifting left, security and DevOps teams can work toward proactively hardening pipelines with the right CI/CD tools and frameworks and push the industry toward a more secure software supply chain. 

  • Linux 6.0 is Faster, Cooler | Debian Goes Proprietary | Google Africa Region

    Linux 6.0 is Faster, Cooler | Debian Goes Proprietary | Google Africa Region

    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: Linux 6.0 promoted to Stable, Debian 12 will include closed-source binaries, and Google Cloud opens its first Africa region. (more…)