devopsy.kinsta.cloud

Category: Doin’ DevOps

  • How Automated Testing Closes the Development and Delivery Gap

    How Automated Testing Closes the Development and Delivery Gap

    For the past two years, companies have leaned into digital transformation projects to keep their digital offerings at pace with their in-person operations. Rather than become a stopgap, this digital approach became the new standard for the modern employee and customer experience. It also creates friction between a company’s development team and its user base. How long should customers wait for new or updated applications in our increasingly fast-paced business environment? Companies need time for development and testing to deliver quality products, but will the demands of their users force them to cut corners?

    Consider each stage of a customer’s journey. Visiting a website or app and putting something into the shopping cart is only the beginning. Behind the scenes, systems that monitor availability, sourcing, loyalty and promotions come into play. Following checkout and payment, there are systems for picking the product, packing it and delivering it with timely notifications along the way.

    Businesses find themselves in a bind when they have to decide which of those areas to cut back on. There’s really no good answer—enter the continuous delivery mindset. We like to say there is no continuous delivery without continuous testing, but those two areas are often at odds with each other.

    The good news is that there is a way to close the gap between customer demand and necessary development time: Test automation. Here are three ways that test automation can help companies satisfy both the needs of their business and their customers.

    Relieving the Testing Bottleneck

    Moving fast is becoming a competitive advantage for many companies. That speed-to-market opportunity has been heightened as cloud-based, low-code/no-code apps like Salesforce, MS Dynamics, Workday and Oracle have become an industry standard. Today, while plenty of development activities may be handled by low-code/no-code platforms, the test automation of these apps remains a high-code, high-maintenance activity.

    To keep from becoming a bottleneck, teams should plan automation and testing strategies early in the process. This is where continuous development includes continuous testing. Suppose companies can make test automation accessible to more people by removing the need for specialized knowledge and daunting technical constraints. In that case, they will be able to streamline ongoing development cycles.

    Ensuring Higher-Quality Output; Aligning Development and Testing

    One of the keys to putting out a higher-quality product is by adopting in-sprint testing, which aligns development and testing efforts. Each feature is tested and automated as soon as it is implemented so that teams can more easily catch errors early rather than at the end of a development phase.

    The automation also elevates the area of regression testing, as teams make sure new changes haven’t broken existing functionality. As automation moves into the mainstream, a wider range of collaborators become more involved in testing each additional feature.

    Creating a Better User Experience

    Historically, testing has been extremely focused on function and is very technical while user experience efforts remain focused on the stylistic and usability end of the spectrum. But creating satisfying end-to-end user experiences is a critical part of any application adoption, so the two sides should work toward a common goal.

    That common link lies in a company’s business processes. Each process is the starting point for building and designing a test scenario. From start to finish, everyone understands the user’s journey and works together toward making that path as effortless as possible.

    Conclusion

    Today’s modern customers don’t expect a measurable difference in experience between online and in-person. Expectations are at an all-time high, leading companies to push updates to their websites and apps more quickly and more frequently. As companies increase their dependence on software, the way to test that software is evolving to keep pace with development speeds.

    Automated testing can simplify and speed up the testing phase, catching many of the basic errors and leaving testers to focus on more complex functionality.

     

  • Connections Matter: Gaining Visibility Into APIs

    Connections Matter: Gaining Visibility Into APIs

    Digital transformation is at the center of modern enterprise. Yet, as cloud initiatives take shape and the complexity of connecting systems and applications multiplies, the need to tie everything together and automate processes grows. APIs, otherwise known as application programming interfaces, fuel this automation. These small pieces of code—which connect and interconnect clouds, containers, microservices and applications—help organizations compress what used to be years of project development into months or weeks.

    As businesses connect functionality—often across companies and service providers—APIs lead to an enhanced user experience. Simply put, they make it possible for much of the magic of the internet to take place, including seamless authentication, data sharing, payments and collaboration.

    Today, it’s next to impossible to find an enterprise application that doesn’t rely on APIs. Yet, despite all the gains, APIs can cause plenty of pain. The slow performance or complete failure of an API can lead to an array of problems. These include customers who can’t complete transactions, employees who can’t collaborate through critical apps, and incomplete or incorrect supply chain data.

    Today, a typical organization relies on more than 1,200 cloud-based applications and hundreds or even thousands of APIs. For many businesses, 50% to 90% of revenues are linked to APIs. If a system underperforms or breaks, there’s often no way to identify the root cause and fix it promptly. Reputational damage and lost sales often ensue.

    When Good APIs Go Bad

    It’s important to recognize that the monolithic applications of the past are a vanishing breed. Today’s highly-distributed software and services environment taps a universe of more than 24,000 APIs. It isn’t unusual for a transaction to pass through several cloud containers and across numerous companies en route to the desired outcome. Along the way, these APIs encounter different hardware, code and conditions.

    When APIs work well, a process or transaction typically finalizes within milliseconds—and the digital experience usually excels. However, if a page loads slowly, a promotional code doesn’t work or payment doesn’t go through, the odds are high that somewhere along the line something went astray with an API.

    For many organizations, there’s no simple and fast way to identify the source of the problem, understand the current impact, and take steps to fix the failure post haste. In fact, it isn’t unusual for several thousand or more failed transactions to pile up before the issue hits IT’s radar and anyone begins to notice a problem. By then, shoppers have likely abandoned shopping carts and sales have evaporated.

    Adding to the challenge is the fact that APIs can fail in several ways. Not surprisingly, the number one problem is availability. If the API doesn’t function, the interaction or transaction cannot take place. In addition, an API might perform slowly or erratically, thus delivering highly inconsistent and frustrating experiences for users along with a problem that is difficult to diagnose and fix. Yet another problem is misconfigured or poorly functioning APIs that return incomplete data or the wrong data.

    The real-world fallout can be significant. In practical terms, a customer shopping at a clothing retailer’s website may find it impossible to add socks to a shoe order or use one or more payment services. It may be impossible to cash in points from a loyalty program or view delivery information. Broken APIs can disrupt or break shopping carts, customer accounts, supply chain data, collaboration links, security tools, and much more.

    Of course, when things go haywire, finger-pointing and conflicts with vendors, business partners and customers often ensue.

    Deep Visibility

    In today’s API-centric world, detecting problems early and often is critical. What makes the task so difficult is that API transactions do not unfold in a linear way. They bounce across servers and companies—often a couple dozen of them—scattered all over the world. Further complicating things: This routing can change at any given instant.

    Identifying specific issues that trigger a problem—traffic bottlenecks, bandwidth issues, code problems and more—requires the right tools. It’s vital to understand how an API-based transaction behaves across a dozen or even two dozen hops and touchpoints that extend through clouds, containers and microservices.

    Passive visibility tools, while useful for getting closer to the end-user, do not offer a comprehensive and granular view of events and processes. Today, businesses require broader and deeper observability capabilities that extend across an ecosystem of APIs and into the entire IT landscape—from network to device. It’s vital to understand how customers use websites, apps and other services.

    Making Integrations Matter

    As organizations delve deeper into clouds and digital interconnectivity, a more nuanced approach that incorporates both passive and active observability is in order. This approach makes it possible to emulate a user journey and quickly identify problem points. A business can detect problems as they pop up—after only a handful of failed transactions—rather than thousands or even tens of thousands of transactions later.

    With a best-practice observability and remediation framework in place, an enterprise can establish baselines and triggers for alerts and notifications. It can assemble a complete picture within a single pane of glass and troubleshoot across the delivery chain. Whether the API involves a collaborative task within the organization or a financial transaction that stretches across several companies, it’s possible to view the entire transaction—and experience.

    With both passive and active monitoring in place, a business can evolve beyond constant fire-fighting mode. Armed with the information and insight required to make vendors more accountable, businesses ensure they are getting the level of service (SLA) they are paying for. Make no mistake, as digital transformation initiatives accelerate and cloud complexity grows, it’s critical to ensure that APIs, microservices and other digital components are up to speed.

  • Clinical Trials: Programming for Scale, Speed and Success

    Clinical Trials: Programming for Scale, Speed and Success

    According to the Journal of the American Medical Association (JAMA), the median cost of bringing a new drug to market is $985 million and the average cost is $1.3 billion. However, those in health care hoping to harness promising new treatments, and patients facing steep prescription costs, see this as progress. After all, previous studies estimated the average price for developing a drug to be as high as $2.8 billion, a cost usually recouped at the expense of consumers. While savings are being realized, trials still come with quite a price tag—but the reasons why are understandable. First, clinical trials are complex and, simply put, time is money. The final stage alone, the Phase 3 clinical trial, can involve tens of thousands of participants, each with hundreds or thousands of data points that need to be tracked over a number of years. This can produce hundreds of millions of data points that must be protected, secured and blinded, and all of which must be analyzed by numerous applications.

    Many cite the fast development of a COVID-19 vaccine as proof that the process can be expedited. While the vetting of these vaccines was thorough, the processes benefited from unprecedented resources, industry and government cooperation and global pressure to quickly find a way to slow a highly infectious disease. Even so, one can’t help but wonder why clinical trials typically take six to seven years? Haven’t we learned how to speed up trials without jeopardizing health or draining budgets?

    The short answer is yes—there is a way to reduce the time and resources needed for clinical trials. Pharmaceutical companies use dozens of software platforms from an array of vendors in their trials. As a result, crucial data gets trapped in unconnected silos, adding complexity and stalling progress. However, by unifying apps and data stores in one integrated system, trial efficiency can be raised and time-to-completion reduced by over 20%.

    Raising a Platform

    Deloitte noted that COVID-19 revealed health care’s need for structural and technology transformation, adding that its future will be “enabled by radically interoperable data, artificial intelligence (AI) and open, secure platforms.” The same holds true for clinical trial data software platforms; however, creating a unified system is an enormous undertaking for software developers and software engineers. Most importantly, any unified system must be able to provide the following four capabilities.

    ● Security: Data in platforms must not only be protected from external threats such as hackers and ransomware but it must also be blinded. The ideal is a double-blind clinical trial in which neither participants nor their physicians know who received the actual drug and who received the placebo.
    ● Modeling: A platform must be capable of extending a data model for each clinical trial to prevent the need to rebuild every time. The models, and the platform overall, must be flexible but still capable of managing hundreds of millions of records across multiple trials.
    ● Extensibility: Over the course of years, data collected—even in a single trial—may change. The ability to extend a scheme on the fly to fit evolving needs can save an enormous amount of time versus building a platform and transferring data. This is especially true when you have millions upon millions of data points.
    ● Ease: A platform must be easy to modify by non-programmers. If a trial designer can implement rules without having to bring in a programmer, the trial will move ahead much more quickly.

    Key to being able to raise an effective clinical trial platform are software engineers and developers. According to the Bureau of Labor Statistics, software developer jobs alone will grow more than 22% by 2029—faster than all other occupations combined. While this is good news for software pros, demand will create a shortage exceeding 1.2 million by 2026, which isn’t so great for the pharmaceutical companies that need talent.

    Then again, there are purpose-built platforms available that provide data, software, services and an ecosystem of partners to support functions from research and development through commercial availability. They’re designed to bring such products to market faster and more efficiently while maintaining complete compliance. The platforms can not only be comprehensive, but they can also mitigate reliance on developers and engineers, with regular provider updates future-proofing operations and decreasing investments.

    Programming for Success

    First and foremost, pharmaceutical companies are achieving faster trial goals by leveraging the cloud and DevOps. In doing so, all data can reside in a central repository that’s accessible from anywhere. There’s no hardware requiring time-consuming manual configuration. What’s more, modern cloud infrastructures are resilient, secure and robust. And all of this is largely being made possible by software-as-a-service (SaaS) platforms.

    Despite this progress, the need to technologically bolster trials continues. AI is now being applied to auto-classify documentation. Naturally, these types of developments require the implementation of programmability and extensibility at scale. The best minds in software engineering have made considerable gains. It’s now up to pharma to ensure their trials and operations continue to be programmed for success.

  • Developer’s Guide to Web Application Security

    Developer’s Guide to Web Application Security

    When it comes to security, there are many vulnerabilities that can leave your website or web app open to attack. In this article, we’ll go over 15 common web application security vulnerabilities and how you can prevent them.

    1. Insufficient Cryptography

    Cryptography is a critical security measure that is used to protect data in transit and at rest. Yet, many web applications do not use cryptography properly, leading to a number of serious vulnerabilities including potentially devastating code theft. For example, data can be easily intercepted and read if it is not properly encrypted or encryption keys can be easily guessed or stolen if they are not properly protected.

    To properly protect data, it is important to use strong cryptography. This includes using proper encryption algorithms, encrypting data in transit and at rest, properly protecting encryption keys and more. It is also important to keep all software up-to-date, as new cryptography vulnerabilities are constantly being discovered.

    2. Broken Access Control

    Access control is a security measure that controls who has access to what data and functionality in a system. It is an important part of any web application but often is not implemented correctly. This can lead to serious vulnerabilities such as sensitive data being leaked or attackers gaining access to administrative features.

    There are a number of common mistakes that can lead to broken access control, such as failing to properly restrict access to data and functionality, using insecure methods for storing and transmitting user credentials and not properly protecting session tokens. In order to prevent these kinds of vulnerabilities, it is important to implement proper access control measures in your web application.

    3. Broken Authentication and Session Management

    Authentication and session management are two of the most important security measures in any web application. Yet, they are very often not implemented correctly, leading to a number of serious vulnerabilities. For example, session ID’s can be easily guessed or stolen, cookies can be tampered with and passwords can be brute-forced.

    In order to properly protect user data and prevent these kinds of vulnerabilities, it is important to implement strong authentication and session management mechanisms. This includes using strong passwords, two-factor authentication, proper session expiration and invalidation, and more. It also means properly protecting any session IDs and cookies that are used by the application.

    4. Cross-Site Scripting

    Cross-site scripting (XSS) is a type of vulnerability that allows an attacker to inject malicious code into a web page. This can be used to steal data, hijack sessions, redirect users to malicious sites and more. XSS is one of the most common web application vulnerabilities, especially in our era of remote work. Despite security awareness training, many employees remain vulnerable to social engineering and phishing tactics when these risks are not properly addressed.

    To protect against XSS attacks, it is important to sanitize all user input and output. This includes properly escaping special characters, using a whitelist of allowed characters and more. It is also important to keep all software up-to-date as new XSS vulnerabilities are constantly being discovered.

    5. Insecure Direct Object References

    Insecure direct object references (IDOR) are a type of vulnerability that allows an attacker to directly access data that they should not have access to. For instance, an attacker could guess or brute-force the URL of a sensitive file, such as a customer’s credit card information, and then download it. IDORs can also be used to bypass security measures such as access control checks.

    In order to prevent IDOR vulnerabilities, it is important to properly validate all user input and restrict access to data and functionality to only those who are supposed to have access to it. It is also important to keep all software up-to-date as new IDOR vulnerabilities are constantly being discovered.

    6. Insufficient Authorization and Authentication

    Insufficient authorization and authentication is a type of vulnerability that allows an attacker to gain access to data or functionality that they should not have access to. This can be due to a number of factors, such as weak passwords, improperly implemented role-based access control, deliberate over-permissioning and more.

    To properly protect data and prevent these kinds of vulnerabilities, it is important to implement strong authentication and authorization mechanisms. This includes using strong passwords, two-factor authentication (2FA), proper role-based access control and more. It is also important to keep all software up-to-date as new vulnerabilities are constantly being discovered.

    7. Failure to Restrict URL Access

    Another common web application security vulnerability is the failure to restrict URL access. This can allow attackers to gain access to sensitive data or functionality that they should not have.

    One of the most common problems developers face is forgetting to properly restrict access to directories and files. For example, they may forget to add an index.html file to a directory. This oversight would give anyone who accesses that full directory read and write access to all the files in it.

    Another common issue is that developers do not properly restrict access to certain URL parameters. For example, they may allow anyone to access the “id” parameter, which could be used to view or modify data that they should not have access to.

    To prevent these kinds of vulnerabilities, it is important to make sure that all directories and files are properly restricted and that all URL parameters are properly sanitized before being used.

    8. Remote File Inclusion

    Remote file inclusion (RFI) is a type of vulnerability that allows an attacker to include a remote file, usually through a script or other type of application, on a vulnerable web page. This can be used to inject malicious code into the page which can then be executed by anyone who views it.

    One of the most common problems with RFI is that developers do not properly sanitize user input, which allows attackers to inject their own files into the page. Another issue is that developers often use static include paths which makes it easy for attackers to guess the path and inject their own files.

    To limit these kinds of vulnerabilities, it is important to make sure that all user input is properly sanitized and that dynamic include paths are used.

    9. Insufficient Logging and Monitoring

    Logging and monitoring are critical security measures that are used to detect and respond to security incidents. Despite these critically important functions, many web applications do not properly log and monitor activity, leading to a number of serious vulnerabilities. For example, an attacker could easily cover their tracks or an incident could go undetected if there is not proper monitoring in place.

    In order to properly detect and respond to security incidents, it is important to properly log and monitor activity. This includes logging all activity, monitoring for suspicious activity and more. It is also important to keep all software up-to-date, as new logging and monitoring vulnerabilities are constantly being discovered.

    10. Security Misconfiguration

    Security misconfiguration is a type of vulnerability that arises when a web application is not properly configured. This can lead to a number of serious security issues such as exposing sensitive data, making it easier for attackers to gain access to systems, and more.

    To mitigate risk when it comes to these kinds of vulnerabilities, it is important to properly configure all software and systems. This includes setting strong passwords, disabling unnecessary accounts and services, properly configuring firewalls and more. It is also important to keep all software up-to-date as new security misconfiguration vulnerabilities are constantly being discovered.

    11. Tampering with Data

    Data tampering occurs when an attacker tries to modify data without permission. This can end up having a number of serious consequences, such as corruption of data, loss of data integrity and more.

    To prevent data tampering, it is important to properly protect data through data handling and storage best practices. This includes using proper authentication and authorization mechanisms, encrypting data in transit and at rest, properly protecting encryption keys and more. It is also important to keep all software up-to-date as new data tampering vulnerabilities are constantly being discovered.

    12. Cross-Site Request Forgery (CSRF)

    Cross-site request forgery (CSRF) is a type of vulnerability that allows an attacker to trick a user into submitting a malicious request. The goal is to be granted requests to do things without the user’s knowledge or consent, such as changing their password, transferring funds and more.

    To prevent CSRF attacks, it is important to properly validate all requests. This includes using proper request validation mechanisms, such as checking for a valid CSRF token, 2FA and more.

    Be Aware of Vulnerabilities

    We use and rely on a large number of web apps in our daily and commercial lives. While most of these apps are relatively safe and secure, there are still a number of common security vulnerabilities that can leave them open to attack.

    To keep your web apps safe and secure, it is important to be aware of these vulnerabilities and know how to prevent them. This includes keeping all software up-to-date, using proper authentication and authorization mechanisms, encrypting data in transit and at rest and training users to identify social engineering and phishing attempts, among others. By following these best practices, you can help to ensure that your web apps are as safe and secure as possible.

  • Cloudflare Outage Outrage | Yet More FAA 5G Stupidity

    Cloudflare Outage Outrage | Yet More FAA 5G Stupidity

    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: Cloudflare suffers another huge outage while the FAA and FCC still disagree over 5G/NR near airports. (more…)

  • Cloud Giants Shun Wind Power? | LaMDA not Sentient? | MS IE RIP?

    Cloud Giants Shun Wind Power? | LaMDA not Sentient? | MS IE RIP?

    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: Warren Buffett asks too much for wind energy, it’s “completely ridiculous” to say Google’s chatbot LaMDA is sentient, and Microsoft finally kills Internet Explorer. (more…)

  • What SREs Can Learn From the Atlassian Outage of 2022

    What SREs Can Learn From the Atlassian Outage of 2022

    What happens when the tools and services you depend on to drive site reliability engineering turns out to be susceptible to reliability failures of their own? That’s the question teams at about 400 businesses presumably asked themselves in the wake of a major outage in Atlassian Cloud. The incident offers a number of insights for SREs about reliability risks within reliability management software itself—as well as how to work through complex outages efficiently and transparently.

    What Caused the Atlassian Cloud Outage?

    The outage, which began on April 4 and finally resolved April 18, affected about 400 Atlassian Cloud customer accounts. Atlassian Cloud is a hosted suite of popular Atlassian products including Jira and OpsGenie. The outage meant that affected customers could no longer access these tools or the data they managed in them.

    According to Atlassian, the problem was triggered by a faulty application migration process. Engineers wrote a script to deactivate an obsolete version of an application. However, due to what Atlassian called a “communication gap” between teams, the script was written in such a way that it deactivated all Atlassian Cloud products, not just the obsolete application.

    To make matters worse, the script was apparently configured to delete data permanently, rather than mark it for deletion, which was the intention. As a result, data in affected accounts was removed permanently from production environments.

    The Good, the Bad and the Ugly

    The Atlassian Cloud outage may not be the very worst type of incident imaginable—failures like Facebook’s 2021 outage were arguably worse because they affected more people and because service restoration was complicated by physical access issues—but it was still pretty bad. Production data was permanently deleted and hundreds of enterprise customers experienced total service disruptions that have lasted several days and counting.

    Given the seriousness of the incident, it’s tempting to point fingers at Atlassian engineers for letting an incident like this happen in the first place. They seem to have written a script with some serious issues, then presumably deployed it without testing it first—which is exactly the opposite of what you might call an SRE best practice.

    On the other hand, Atlassian deserves credit for responding to the incident efficiently and transparently. Although the company was silent at first, it ultimately shared details about what happened and why even though those details were a bit embarrassing to its engineers.

    Crucially, Atlassian also had backups and failover environments in place, which it used to speed the recovery process. The major reason why the outage lasted so long, the company said, is that restoring data from backups to production requires integrating backup data for individual customers into storage that is shared by multiple customers, a tedious process that Atlassian apparently can’t perform automatically (or doesn’t want to, presumably because it would be too risky to automate).

    Unfortunately for impacted customers, it does not appear that any fallback tools or services were made available while they waited for Atlassian to restore operations. We imagine this poses more than minor issues for teams that rely on tools like Jira to manage projects and OpsGenie to handle incidents. Perhaps those teams stood up alternative tools in the meantime – or perhaps they crossed their fingers, hoping their project and reliability management tools would come back online ASAP. 

    Takeaways for SREs From the Atlassian Outage

    For SREs, then, the key takeaways from this incident would seem to be:

    • Always perform dry runs of migration processes in testing environments before putting them into production. Presumably, if Atlassian engineers had tested their application migration script first, they would have noticed its flaws before it took out live customer environments.
    • Back up, back up, back up—and make sure you have failover environments where you can rebuild failed services based on backups. While this outage is bad, it would be 100 times worse if Atlassian couldn’t restore service based on backups and data had been lost permanently.
    • Ideally, each customer’s data should be stored separately. As we noted above, the fact that Atlassian used shared storage seems to have been a factor in delaying recovery. That said, it’s hard to fault Atlassian too much on this point; it’s not always practical to isolate data for each user due to the cost and administrative complexity of doing so.
    • SRE teams would do well to think about how they’ll respond if their reliability management software itself goes offline. For example, it might be worth extracting and backing up data from your reliability management tools so you can still access it if your tool provider experiences an incident like this.
    • Over-communicate with your customers often and early. In this case, there was initial radio silence that left customers in the dark. Most of this chatter eventually took place in public forums.

    Conclusion

    The Atlassian Cloud outage is notable both for its length and for the fact that, ironically, it took out software that teams use to help prevent these types of issues from happening at their own businesses.

    The good news is that Atlassian had the necessary resources in place to restore service as quickly as possible. A shared data storage architecture led to slow recovery, which is unfortunate; again, it’s hard to blame Atlassian too much for not setting up dedicated storage for each customer.

  • How to Get the Supply Chain Back to (Better than) Normal

    How to Get the Supply Chain Back to (Better than) Normal

    If a chain is only as strong as its weakest link, today’s supply chain is in dire straits. A recent infographic from The New York Times shows all too clearly that the international supply chain is in upheaval, due directly or indirectly to the outbreak of COVID-19. At the same time, reams of data generated along the supply chain are going to waste. The internet of things (IoT) can’t single-handedly fix the supply chain, but IoT technology combined with the cloud, AI and automation has the potential to bring the supply chain (and society) back to something resembling normal—actually, something better than normal.

    Indeed, even during “normal” times, the supply chain was stretched to the limit by the challenge of constantly reducing costs and improving margins, as well as optimizing delivery times for just-in-time (JIT) inventory. With that said, the last two years have been especially grim, with factories, stores and restaurants literally shutting down for lack of materials. Then there’s the computer chip shortage, which is doing nothing less than “dragging down the economy,” according to a White House briefing room document,

    The problem is now multifaceted, so the solution is not going to be as simple as adding a better monitoring mechanism.

    At a minimum, companies need better visibility into and transparency of their supply chains. This gives them more control over the entire manufacturing process, from sourcing raw materials to delivery of final products. Technologies like IoT, AI/ML, automation and edge computing can optimize supply chain management by providing visibility and metrics so companies can make real-time decisions.

    In manufacturing, for example, IoT can bring greater visibility into the production workflow. Data from the digital twins of machinery—analyzed in real-time and fed back to control systems—can lead to improved levels of operational and business efficiency. When manufactured goods are ready to be shipped, IoT technology can guide the logistics and transportation of goods as they move from manufacturers to end users. In addition to managing supply, companies also need to get better at predicting customer demand so it’s a self-sustaining feedback loop.

    However, companies adopting these technologies need to be aware that they will not be effective on their own. As with any digital transformation initiative, people and processes are as important as technology. To ease or even overcome today’s supply chain challenges, companies must not only agree on common data exchange formats and APIs across the supply chain but also dedicate themselves to ongoing cooperation and motivation to achieve the common goal of streamlining and hardening the supply chain. To these ends, open source will be critical to the ongoing development of common, industry-wide standards that enable companies to future-proof their solutions.

    For example, carmakers such as Tesla are simplifying their supply chain by using a higher-end processor that can perform multiple functions rather than using dozens of dedicated microcontrollers for each function, with updates pushed out over the air. Organizations need to think along similar lines when it comes to their IoT architecture. Developers have historically thought about IoT applications in a discrete way—creating custom frameworks for creating apps for low-power devices. Rather, developers should be considering IoT applications as an extension of their application portfolio—using the same languages, frameworks and tools for IoT apps that they use for cloud applications.

    Post-Pandemic Supply Chain Issues

    As we move into the next phase of the pandemic, it might be tempting to believe that all will be right with the supply chain world. However, beyond COVID-19, there are several macro trends that will affect the supply chain, including climate change, cybersecurity and the changing dynamics of global trade.

    To combat climate change, for example, companies will need to reduce their Scope 3 emissions. The EPA defines Scope 3 emissions as the result of activities from assets not owned or controlled by companies themselves but by their supply chain (or value chain). Scope 3 emissions are often the majority of a company’s greenhouse gas emissions. To reach sustainability goals, companies will need better resource management of their supply chains.

    Supply chains also are increasingly being used as a cyberattack vector. This includes both physical entities, like building operations (such as the hack of Target systems via a third-party HVAC vendor) or the software supply chain (such as the SolarWinds hack). In fact, it’s no longer a matter of if an organization gets attacked, but when.

    The war on Ukraine has magnified the intricacies of our hyperconnected global economy. The U.S. government and its allies have imposed severe sanctions on Russia, a move that will have widespread repercussions. The New York Times reported that the “response that U.S. officials have promised could roil major economies, particularly those in Europe, and even threaten the stability of the global financial system.” The same could be said for the global supply chain, if Russia responds by, for example, cutting off shipments of materials needed to build semiconductors or mounting new cyberattacks.

    Conclusion

    COVID-19, a steady and stealthy rise in cyberattacks, trade barriers, war … None of these factors caused the problems we’re seeing with both physical and technological supply chains; rather, they have exposed existing weaknesses for all the world to see—and experience. Organizations must work together to increase resiliency and security through the use of key technologies such as IoT, AI/ML and edge, as well as a commitment to open, standards-based solutions.

  • Why Over-Permissive CI/CD Pipelines are an Unnecessary Evil

    Why Over-Permissive CI/CD Pipelines are an Unnecessary Evil

    Balancing the speed of innovation with security is an age-old problem in software development. This is no different in modern DevOps. Development teams want a frictionless path to deploy new code but often struggle with access permissions that are linked to services. The CI/CD pipeline makes it easier for developers to quickly introduce new features and updates, in an agile way. As application changes move through the CI/CD pipeline, automation can allow changes to happen very quickly, without creating downtime or delays on the customer side.

    Permissions of CI/CD Servers

    When it comes to the permissions of CI/CD servers, DevOps often don’t want to deny access. After all, the wide access permissions are part of allowing the speed of innovation, and development teams are regularly—and often understandably—cautious about putting least-privilege or other access rules in place.

    But there are some security risks to consider. Any developer being granted admin permissions to deploy new code is open to vulnerabilities, weaknesses and misconfigurations. Cloud sprawl has created a lack of visibility into whether or not the infrastructure is properly set up and connected with logging tools. How does the development team know if things are getting properly patched?

    The balance is extremely sensitive. DevOps need the speed of change and the ability to innovate freely, but security teams can’t handle the growing risk. Something has to change that can allow security to shift left and get involved earlier in the CI/CD pipelines rather than getting in the way.

    Reducing the Risk Without Impacting Innovation

    Here are some suggestions for accelerating the speed of innovation while maintaining a healthy security posture:

    • Map threats and secure connections. Conduct a threat modeling exercise to map threats to the pipeline. Remember that every connection to the CI/CD pipeline is a potential point of compromise. Regularly patch and scan all services that connect to the pipeline and block the devices if they fail to meet security policy requirements.
    • Learn to love logs. When a security issue arises in production, developers, IT engineers and security engineers need to react quickly and efficiently to solve the problem. Logging is critical for enabling fast and coordinated responses. Waiting on manual sharing of sensitive data can slow down reaction times. But when every stakeholder can get the data they need from logs, access to information is no longer the weakest link in the security incident remediation process.
    • Tighten access control and enforce strong admin permissions. Be specific about who has access to which data. Clear and enforced separation of duties should ensure no one person or account can access more than necessary in the continuous software delivery pipeline. Improperly credentialed users or bad actors can’t establish control over the entire pipeline and mess with the code or processes. Moreover, they won’t easily be able to penetrate deeper into other corporate systems and data.
    • Leverage flags to manage risks. Developers often use feature flags (or feature toggles) to add new features to applications while mitigating the risk that those features will introduce performance or stability issues. Although most developers likely don’t think of feature flags as a security tool, they can be used for that purpose, too. New features are prime vectors for security vulnerabilities, especially if developers haven’t thoroughly tested them yet.

    Many security teams do not realize that just because their network is private, they’re still sharing pipelines with third parties, including anyone from maintenance to the team deploying your mobile app. By embracing these tools, developers can shift left, shoring up defenses early in the process, without adding a blocker to the pace of innovation coming from DevOps CI/CD pipelines.

  • How Waterfall Methodologies Stifle Enterprise Agility

    How Waterfall Methodologies Stifle Enterprise Agility

    In this age of sweeping digital transformation and accelerated change, organizations are recognizing that depending solely upon the drawn-out process of waterfall methodology is no longer sustainable if they are to remain competitive and relevant.

    Enterprise infrastructure must incrementally embrace evolution from monolithic architectures in response to the escalating pace of technological innovation, ever-changing consumer needs and demands and the failure of a long-running single project focus.

    EA Must Continuously Adapt 

    Traditional enterprise architecture (EA) frameworks struggle to manage the impact of disruptive technologies and systems that are agile and flexible. An architecture design approach that embraces continual evaluation and iteration is better equipped to navigate change and capitalize on emerging trends and innovations. Adaptability, in this context, may be defined as the fluid ability to modify, restructure and recreate the architecture in relation to changes within and external to the enterprise. It involves the early identification and rapid response to new product concepts, important trends, events and consumer demands; developing a “from the outside in” perspective.

    This adaptability, or ‘evolvability,’ quotient enables the flexibility and agility to deliver services and products reliably in this new development norm. Enterprise leaders are quickly acknowledging the need to inject a more open and agile format into their enterprise’s processes, at least in some measure, to succeed in today’s unpredictable environment.

    The Waterfall Model Constrains Enterprise Agility

    Traditional organizational architecture can impose limitations on an enterprise’s ability to successfully reach its digital transformation goals. The up-front model, with a focus on one long-range project, can slow productivity and choke creativity. While planning is needed as agility scales, the detailed technology life cycles with large timeline projections are no longer effective or profitable in meeting the business mandates that drive enterprises forward. Enterprise leaders are increasingly abandoning the five-year architectural plan for one that is designed to evolve with the ever-changing software development environment.

    Enterprise architects must now develop and promote adaptive methods that support agility in order to appropriate the value of new technologies like AI, machine learning, big data, IoT and intuitive tools that enable advanced analytics and enterprise-wide collaboration. A less intentional architecture, decomposed into smaller units, can be managed by autonomous cross-functional teams that are accountable to peers and managers with shared strategic objectives, bringing all fields into a coherent whole.

    A continuous architecture design with no end state, guided by iterative changes, will fluidly address the changing needs of the enterprise. A shift from a project-oriented to a product-oriented management mindset leads to faster learning cycles, shorter time-to-market, higher quality and increased revenues.

    The Attributes of a Flexible and Adaptive EA

    An open architecture designed to evolve in an ongoing manner and enable agility will include many beneficial characteristics and principles. Flexible and adaptive EA:

    • Provides product-centricity that connects software development to business goals;
    • Explores multiple solutions simultaneously with shorter analysis, testing, experimentation cycles and progression to eliminate weak solutions;
    • Empowers autonomous, cross-functional teams with clear accountability roles and alignment to a shared mission statement and effective information sharing;
    • Enables flexible and efficient resource allocation driven by changing demands or activity levels;
    • Strengthens an evolving roadmap that shows vision and targets, open to the whole enterprise, to allow input and questions for collaboration, cohesion and transparency;
    • Facilitates incremental changes to software architecture in a continuous manner;
    • Provides a continuous integration and delivery model with automatic testing for ‘good enough’ MVPs to keep the business moving forward.

    An adaptive EA allows for timely decision-making as agility scales, ensuring that the right products are delivered at the right time in alignment with business initiatives. When design accountability is distributed across the enterprise, consensus on complex decisions involving diverse stakeholders is more easily attained.

    The business rewards of transitioning to an adaptive architecture should be an easy sell by examining and tracking the monetary, time and customer success gains. The evolution toward adaptive enterprise architecture can reap numerable benefits. In addition to fostering an enterprise culture of continuous improvement, it accelerates and improves development cycles, journeys and outcomes for stakeholders and customers.

    Adaptive EA addresses the inherent uncertainties and complexities associated with dynamic business changes. It can deliver the rapid incremental changes, capabilities and benefits that a waterfall model inhibits. The agile and open methodology, empowered to continually evaluate and modify, provides visibility into project requirements and feasibility to reduce risks typically experienced with a traditional design and waterfall methodology.

    Making the Transition to an Agile EA

    Transforming enterprise architecture to a more adaptive and agile model will require planning and investment. A necessary first step is to assess what the enterprise goals and objectives are in making the transition. To what degree is the organization ready and what needs to be in place in order to move forward?

    Investing in an enterprise-wide training program of agile technologies, principles and methodologies will develop a cohesive and cooperative mindset that overcomes resistance to change and optimizes transition success.

    Of utmost importance is the development of a culture of communication, from the C-suite down across all stakeholders. A shared vision must be communicated and encouraged within a collaborative framework to cultivate enterprise-wide buy-in and acceptance of changes from waterfall methodologies to current roles and practices. In the migration to agile, there can be many obstacles, but by adopting an incremental approach with frequent reassessments an enterprise can ease the transition.