devopsy.kinsta.cloud

Category: DevOps Practice

  • ShiftLeft Report Reveals State of Application Security

    ShiftLeft Report Reveals State of Application Security

    A report published today by automated application security testing platform ShiftLeft found only one in three applications has an attackable vulnerability. The report also found organizations that prioritized their remediation efforts based on the level of actual threat are fixing 76% of those vulnerabilities within two sprints lasting 12 days, on average.

    Based on millions of scans performed in the last year using the ShiftLeft platform to identify vulnerabilities, organizations have reduced the number of vulnerabilities they need to address by 97% on a year-over-year basis, the report found.

    In addition, the report noted that the average median scan time is only 90 seconds, which helped drive an overall 68% increase in daily scans year-over-year. Overall mean-time-to-remediate (MTTR) has dropped by 37%, the report also found.

    ShiftLeft CEO Manish Gupta said given the increased number of vulnerabilities, it’s more critical than ever for organizations to focus their remediation efforts on those that can be exploited within their IT environment. For example, the report found that only 4% of all Log4j instances discovered in the IT environments analyzed were vulnerable. Rather than spending weeks looking for every instance, Gupta said IT teams would be much better off focusing their efforts on the instances that might actually be exploited.

    The challenge is that not enough organizations have a way to score vulnerabilities based on the risk they represent to the business, Gupta added.

    While there is a lot more focus on adopting DevSecOps best practices in the wake of a series of high-profile breaches of software supply chains, the ShiftLeft report made it clear that presenting developers with a long list of potential vulnerabilities is counterproductive. The bulk of vulnerabilities that are being discovered are not actually attackable, noted Gupta.

    That doesn’t mean application security doesn’t need to improve, but it is clear that a lot of time and effort is being wasted, added Gupta.

    In theory, at least, as the cultural divide been application development teams and cybersecurity teams continues to narrow, the overall ability to prioritize remediation efforts should improve. The first step toward achieving that goal is making it easier to identify what percentage of the application attack surface is really vulnerable. Otherwise, developers presented with a long list of theoretical vulnerabilities will continue to prioritize developing new features and capabilities versus remediating vulnerabilities.

    One way or another, vulnerability remediation issues will soon come to a head. In the wake of an executive order from the Biden administration to improve overall application security within federal IT environments, many organizations will adopt similar policies and processes. Developers, naturally, will inevitably either push back or do an end-run around processes they deem too onerous. Rather than allowing a stalemate to occur, Gupta said savvy DevOps teams will invest more time in identifying the critical vulnerabilities that need to be addressed before cybercriminals exploit them.

    The issue, of course, is that cybercriminals are getting more adept at discovering and exploiting those very same vulnerabilities.

  • What the New OWASP Top 10 Changes Mean to Devs

    What the New OWASP Top 10 Changes Mean to Devs

    The open web application security project (OWASP) recently updated its top 10 list of the most critical security risks to web applications after four years. It represents the most radical shake-up since the list was introduced in 2003. The changes will undoubtedly have a big impact on how businesses address application security going forward and how developers and DevOps teams approach their jobs. This article will look at three of the most significant changes that have emerged in the new top 10 list.

    OWASP

    New Methodology for Current and Future Threats

    This time, OWASP took a more data-driven approach to their research to get better insight into current and future threats. Members provided more than 1.5 million data points on the security threats they see. OWASP categorized the data and assigned an impact score before deriving their overall ranking.

    OWASP also included survey data from security professionals about emerging threats. For example, the current incident rate of server-side request forgery (SSRF) vulnerabilities is low, but security professionals consider this attack very serious and expect it to increase significantly in the future. SSRF enables attackers to use vulnerable servers to request and receive data from protected internal sources, which is a very serious risk. So, SSRF became a new category (A10:2021) this year.

    With this new methodology, OWASP is now able to offer comprehensive insight into the most serious current and future threats.

    OWASP 10 Expands Security to the Left

    One key change in the new top 10 list is the inclusion of many categories (e.g, Insecure Design—A04:2021, Software and Data Integrity Failures—A08:2021) that recognize the industry has to start with better application design practices to improve security.

    Many application vulnerabilities creep into software because secure design principles are not followed from the outset. In the race for faster app development, corners are being cut. The CI/CD approach to application development is a major contributor to the use of plugins, libraries or software modules of dubious integrity. This problem is getting worse. Businesses must ensure that all their software components are from reputable sources and should use software supply chain tools to check for known vulnerabilities.

    Major Ranking Changes due to the Evolving Threat Landscape

    Injection attacks, which have been ranked as the number-one risk since 2003, are now ranked number three. While this is welcome news, we cannot claim victory just yet. Your valuable data is still very much at risk from vulnerable apps that allow bad actors to run unauthorized commands and access the sensitive corporate information your business depends on.

    Injection attacks have been replaced by broken access control (A01:2021). OWASP reported that in their data set 94% of applications were tested for these vulnerability types and 3.8% showed one or more weaknesses. A staggering amount!

    Due to the increased adoption of standardized authentication frameworks which are more readily available and easier to implement, identity and authentication failures (A07:2021) have plummeted in the ranking from number two to number seven as a risk.

    This shift demonstrates that as businesses have improved their determination of who can access applications, they have neglected to enforce controls over what an individual user, process or device can do in that application. It is crucial to consider authentication and authorization together for a better security posture.

    Lots of Work Ahead to Bring Left and Right Security Together

    The 2021 OWASP top 10 list is a big step forward. OWASP’s expansion of security to the left with the inclusion of new categories and significant changes to their rankings will require businesses to revaluate their application security posture. Addressing security earlier in the application development life cycle will likely prevent many of the more common attacks, but businesses must complement this with robust, proven and scalable security protections on the ‘right’ like web application firewalls. It is not just about shift left, it is about expand left. You need both left and right security for a better multilayered security posture.

  • The Age of Software Supply Chain Disruption

    The Age of Software Supply Chain Disruption

    The software supply chain is swiftly becoming a widespread attack vector, and securing it is now in the spotlight. Software supply chain attacks have become a given in 2022, reports Darktrace.

    SolarWinds, Kaseya and GitLab are just a few examples of organizations that have been vulnerable to attack in recent years. We’ve also witnessed an increasing number of exploits, like Log4j and Log4Shell that have the potential to affect billions of devices. What these instances have in common is they leverage vulnerabilities in open source software and third-party dependencies commonly used in the software delivery process — meaning one corrupt package could have broad encompassing impacts on the tech industry at large.

    I recently chatted with Doug Dooley, COO, Data Theorem, about the consequences of today’s intricate software supply chains. “The software supply chain problem is bad, but it’s only going to get worse in the next five years,” he said. According to Dooley, application security requires a continuous context of how the app functions at runtime in a software ecosystem—otherwise, it will continue to miss gaping holes in the big picture.

    Understanding Software Supply Chain Disruption

    Most people understand what a traditional product supply chain is—it encompasses all the components involved to bring a product to the end consumer, from raw materials to manufacturing, distribution and retail locations. But, amid the pandemic and recent international conflict, we’ve witnessed how brittle this chain is. If you shut down one of these components, all consumers feel the effect, resulting in everything from gas hikes to baby food shortages. A full 61% of organizations were hit by supply chain attacks in 2021.

    In software, the supply chain can be thought of similarly—there are many components involved between a software product and the end consumer. The developer writes code, integrates third-party libraries and frameworks, puts it in source code systems, pushes it to test environments and eventually deploys it to production. And often, DevOps has the view of this whole picture.

    “DevOps has become some of the most powerful people in the business,” said Dooley. “They can take a business person’s idea and turn it into reality in the form of an application.”

    Third-party exposures can create huge disruptions in this above workflow. This could take the form of insecure libraries, underlying cloud vulnerabilities or API vulnerabilities, says Dooley. “Customers will embed APIs in the software stack—to them, it’s a black box.” There’s also the potential for misconfigured S3 buckets, which continually leak millions of records. More serious application security threats include remote code execution, which can invoke a detrimental loss of control.

    Why Now?

    So, why the sudden peak in software supply chain-related security incidents? After all, open source software, APIs and third-party vendors have been around for decades. Well, according to Dooley, there are several factors at play here.

    For years, the Silicon Valley mantra has been to ‘move fast and break things.’ Take Netflix engineering, for example, which is constantly evolving services and releasing dozens of changes per day. According to Dooley, such rapid application development often means that security is following development rather than preceding it or becoming integrated into the process, à la DevSecOps. This could lead to what he calls an “ambulance chaser moment.”

    The attack surface is heightened as the number of third-party suppliers and dependencies increases. The average company has 254 SaaS apps, Productiv data found. Also, on the attacker side, we’re seeing increasing levels of automation and sophistication. “You only have to be right one time when attacking,” said Dooley. “The deck is stacked in an attacker’s favor.”

    Strengthening The Chain

    The software supply chain issue is a complex problem that won’t be solved by any single action. However, Dooley offered several tips for companies to consider as they confront this broad problem:

    • Source code analysis and vendor management. It’s important to vet partners and have a process to audit new software by scanning for common vulnerabilities and exposures (CVEs). Yet, source code analysis falls short in many areas, admitted Dooley, as it is unlikely you will be able to view the source code behind cloud API calls and production behavior doesn’t always match documentation.
    • Continuous runtime security monitoring. New exploits are being found constantly. Thus, organizations require a continuous defensive posture at runtime, even if they were found to be secure in development. Continuous full-stack discovery must consider many third-party components, like SDKs, open source code, mobile apps, web services, cloud services, APIs and identity and access management, explains Dooley.
    • Increased transparency with SBOMs. More widespread use of software bills of materials (SBOMs) will be critical to increasing transparency across the industry. Just as nutrition facts describe the food we eat, SBOMs spell out the internal makeup of software components. “We’re trying to get to a place where we get more transparency into the software we depend on,” Dooley said.
    • Rapid vulnerability detection. Have a good handle on the attack surface. Businesses will want to collect an accurate inventory of what can be attacked.
    • Build protection around the “crown jewels.” Sometimes, you must prioritize which steps to take first. Dooley reiterated that securing applications that interface with customer data is critical, as these are the “crown jewels”—leaks here could have serious consequences around regulatory penalties and brand reputation.

    Caution: Heavy Lifting Required

    “The moment you ship a piece of software, you’ve taken on a risk,” said Dooley. But at the same time, if you’re not creating digital interfaces, you’re missing out on massive opportunities.

    Reusing code and open source packages have become necessary to maintain agility to help continuously release digital products. “Even if you build everything from scratch, you’re still reusing a lot,” said Dooley. “Without it, you’d never get to market.” While these tools enable unprecedented speed, we can’t overlook the potential vulnerabilities that may lie within the software supply chain.

    With its unique window into the software deployment and automation process, the DevOps sphere will undoubtedly have a role to play in protecting this paradigm. “Let’s push for more transparency and disclosure,” said Dooley. “But don’t hang your hat on that to make your program great—if you really care about this problem, you’ll have to do some heavy lifting in the real world.”

  • Four Steps to Avoiding a Cloud Cost Incident

    Four Steps to Avoiding a Cloud Cost Incident

    The recent Flexera 2022 State of the Cloud Report found that organizations waste 32% of their cloud spend, up from 3o% last year. This can be due to cloud cost incidents triggered by unused resources, malicious activity or overambitious projects and which have a massive financial impact if not found and corrected promptly.

    As an organization’s cloud infrastructure footprint matures, mapping cloud resource use and costs accurately to product lines, teams and business units becomes progressively more complicated and problematic. However, accurate cloud cost attribution is vital to understanding team resource use and determining accurate cost of goods sold (COGS) margins and is imperative to budgeting and forecasting. Organizations need reliable, granular views of the cloud environment to attribute costs back to departments and optimize a meaningful budget.

    Cloud cost spikes can blow up an organization’s budget fast and can be hard to track down, but enterprises can help protect themselves from a cloud cost incident with just a few simple steps.

    Have a Strong Tagging Strategy That Attributes Cost Granularly

    The cloud operations team needs to identify what is important to business reporting, which will help define and create a strategy for tagging. For instance, when an organization has two teams managing a particular service, the teams should safeguard the services tagged with a team identifier. Also, the teams should add another tag for the environment in which they’re running so they can allocate cloud costs across teams and environments.

    When an application uses numerous resources, like a database and storage, teams should consider adding a specific application tag and break down costs by each application. It should be noted that there is no one-size-fits-all tagging solution, so enterprises will need to determine what works and try out different strategies by adding and removing tags later.

    Understand Cloud Cost Ownership to Avoid Chaos

    Ask yourself how well your organization has attributed cloud costs to teams, applications or COGS. If the answer is “Not well,” then you are missing vital information about how your cloud costs relate to your business.

    The lack of this context or visibility into resource allocation makes it unmanageable and impossible for cloud operations owners and senior leaders to agree on who is responsible for varied expenses and resources. Manual cost attribution doesn’t scale accurately or account for shared cluster resource use across teams and applications. This creates confusion that can escalate when users arbitrarily slice data and claim ownership without accountability or clear visibility.

    What happens is that costs can sometimes be double-counted with two owners—or even missed completely with no owner whatsoever. The resulting data emerges as an inferior quality that is untrustworthy and not actionable. The inability to visualize resource use in context can dilute, hinder and even defeat cost improvement initiatives and optimization.

    Cloud costs should have an owner who can ensure that cloud spending is tied to business value. Understanding who owns which pieces will help pinpoint the cause.

    Establish and Monitor Cloud Budgets

    Historical data on cloud spending is gold—it can help forecast and budget for what should be happening with the cloud’s cost footprint. If that’s not happening, then it should be flagged and investigated.

    Once you get cost data under control, organizations can get an accurate picture of where cloud spending is taking place. However, does this match the expectations of spending? By establishing and monitoring budgets at every stage of a project, organizations can have guardrails to cloud spending and prevent costs from soaring out of control when engineers overallocate on performance “just in case.” Once budgets are in place, organizations can monitor spending and right-size resources to balance actual usage, rather than estimated usage at the start of execution.

    Over time, right-sizing resources will allow for optimal spend, as well as identify unused resources that can be shut down. Organizations should identify development and test instances left running when no longer needed and shut them off.

    Implement Cost Anomaly Detection

    Organizations can shield themselves from cost anomalies by continually monitoring and optimizing cloud costs. Cost anomaly detection can help act as a barrier to early recognition before they become problematic. This is especially effective when prompt, actionable alerts can be delivered directly to resource owners via Slack or email when their forecast exceeds the set budget. The best option would be adopting a cloud cost monitoring and optimization (CCMO) tool that gives alerts in real-time when a cost anomaly occurs. These tools must be able to detect anomalies and analyze their root cause, while also allowing visibility into what went wrong to avert similar future errors.

    Executing continuous cost monitoring and anomaly detection tools for dynamic cloud environments is essential in identifying any activity that doesn’t align with expected expenditure or diverges from an established pattern. With proper monitoring, organizations can take corrective measures before the fact.

    Unwanted and unexpected cost incidents can clean out an enterprise’s budget quickly, especially as its cloud infrastructure grows. Organizations need to practice these steps to gain a full picture view of their cloud environment.

  • At Some Point, We’ve Shifted Too Far Left

    At Some Point, We’ve Shifted Too Far Left

    Those of us involved in DevOps have a tendency to see the world with blinders on. It is rather easy to fall into the “If all you have is a hammer, everything looks like a nail” trap. We have used the phrase “shift left” with the attitude that this is the solution to every problem in IT.

    Just for clarity, it is not. That is as blunt and unambiguous a statement as I can make. DevOps is great and has helped in many areas, but it is not the only solution, and not every problem is a DevOps toolchain problem.

    In the end, much critical work in IT is not DevOps-related, nor can it be impacted by DevOps. I’ll mention two areas that are obvious and talk in-depth about one of them.

    First off, no matter how far down the Agile/DevOps trail you travel, the wagon you are riding in is separate and distinct from the DevOps process. If you have a data center, all that hardware is still, in the end, hardware that must be configured and managed. For the “But we’re 100% in the cloud!” crowd (who say that loudly and forcefully enough that I suspect they’re trying to convince themselves that this is a good thing)—in the end, you are still using a network and computers to connect. The massive work-from-home migration due to lockdowns made it abundantly clear that IT is needed to set up and support both. Some of the horror stories coming across ops and DevOps social media were … ugly. Employees don’t want to be—and should not need to be—IT specialists to get their job done.

    The other easy one is security. Yes, insert security into development and DevOps workflows. Yes, make operations staff more aware of security. Yes, automate security as much as possible because we’re chronically short of security staff. But, in the end, lots of security is external to DevOps. While Kubernetes security is absolutely DevOps, password management, for example, absolutely is not. And that’s just one of many, many examples.

    So I am going to ask (but not answer) the question: Where is the line? How far left is too far? The answer is yours to decide with regard to your organization and the tools/environment that exist in your organization. In a primarily cloud environment, the answer to this question is far different than in a primarily data center environment. It is rare that any organization be purely one or the other at this point in time, so there are similarities, but few exact solutions we can name.

    Security is akin to a cost center. It is actually insurance, but few orgs view it that way. And even if they did, it would not make much difference. Much as my father once declared that he and Mom were “insurance poor” and canceled half their policies, most orgs want to contain the costs of security whether they admit it or not. When ‘security merged into DevOps’ hits the ears of people trying to stretch budgets just as far as they can, bad things tend to happen.

    DevSecOps implements security where it should have been all along—at the development stage—but it does not replace other security, it just makes our apps more protected. There are cases where security testing hours are seriously reduced, but since testing in all forms is the first thing to go when staffing is tight, again, it is not replacing something that was happening—it is making it possible for us to do what we should have been doing all along.

    It doesn’t help that our toolchains have taken on lives of their own—at many organizations, staff are required to maintain them—because they, too, are apps that DevOps struggles to help. Once you’ve invested time and money in building that edifice, you want to use it as much as possible. So, many orgs want to shift left everything in IT, right into the toolchain octopus.

    You know your org better than anyone. You are the ones making it work day in and day out, in all of your environment’s glorious complexity. Start talking about what is too much; when adding a step in an already complex toolchain needs to be justified. Push back against everything needing to shift left (where appropriate, I’ll say again for clarity, DevOps has done amazing things for us, but too much of a good thing is our living nightmare and, historically, is tomorrow’s technical debt). Keep rocking it, and make sure you are rocking the right things in the right places.

     

  • Survey Uncovers Depth of Open Source Software Insecurity

    Survey Uncovers Depth of Open Source Software Insecurity

    A survey from Snyk and the Linux Foundation published today found that less than half of respondents (49%) work for organizations that have security policies in place for the use or development of open source software.

    The survey, which polled 550 software development professionals, was conducted by Snyk, a provider of tools for securing software, and the Linux Foundation. Just under a third (30%) of respondents without any policies in place also admitted that no one on their team is currently directly addressing open source security. A total of 41% said they didn’t have high confidence in their open source software security. Nevertheless, 59% of respondents said the open source software they deployed is somewhat or highly secure.

    Matt Jarvis, director of developer relations for Snyk, said many organizations are not aware of the degree to which open source software is now being targeted by cybercriminals looking to surreptitiously insert malware into widely used software projects. Those same organizations also lacked clarity about how open source software is constructed, he added.

    In many ways, the open source software community has now become a victim of its own success, noted Jarvis.

    Overall, the survey found the average application development project has 49 vulnerabilities and 80 direct dependencies on open source software. Only 18% of respondents said they are confident of the controls they have in place for their transitive dependencies. A full 40% of all vulnerabilities discovered were found in transitive dependencies.

    Only a third of respondents (33%) are using static application security testing (SAST) tools within a continuous integration process or software composition analysis (SCA) tools to discover those vulnerabilities, according to the survey. Overall, 44% reported they use some type of tool to analyze source code.

    In terms of additional capabilities, 59% said they would like to see more intelligence added to these tools, while 52% cited a need for more clearly defined cybersecurity best practices. Nearly half (49%) also wanted increased automation and tools for conducting security audits.

    The survey also found that fixing vulnerabilities in open source projects takes 19% longer than in proprietary projects.
    Among organizations that do have security policies in place, 80% vested responsibility with the security team. Only 40% of organizations without such policies did the same, according to the survey.

    The Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation, is focusing on 10 streams of investment that, in total, would require more than $150 million in funding to drive greater adoption of DevSecOps best practices among maintainers of open source software projects. Developers today routinely reuse open source software. The issue is that many of those projects are maintained by a small number of programmers that voluntarily contribute their time and effort to build components that others are free to use. Like any other developer, the amount of security expertise those individuals have is limited. The onus for making sure the projects and software are secure is on the organizations that decide to deploy that software.

    Unfortunately, many IT vendors and large enterprise IT organizations reuse that code without contributing anything meaningful back to the project—whether that be in terms of financing or helping open source maintainers find and remediate vulnerabilities. Hopefully, following an executive order issued by the Biden administration, the level of open source security will steadily improve in the months ahead.

  • TechStrong Con: Downturn Brings Additional Sense of DevOps Urgency

    TechStrong Con: Downturn Brings Additional Sense of DevOps Urgency

    Regardless of whether the overall economy is experiencing a correction or is on the cusp of a recession, organizations are going to prioritize some projects over others as resources become more constrained.

    During the “DevOps: Has the Bubble Burst?” panel made up of DevOps executives and investors from venture capital firms that kicked off the virtual TechStrong Con event today, panelists said organizations will need to continue to invest in DevOps automation and cybersecurity to ensure their long-term survival.

    However, the number of IT projects that organizations will be able to simultaneously invest in is likely to decline, said Chenxi Wang, general partner for Rain Capital. “We are starting to see a slowdown of projects, for sure,” she said.

    Fundamentally, organizations will need to decide not so much whether they will modernize legacy monolithic applications but rather at what rate. More than 70% of organizations’ codebases are still based on legacy monolithic architectures, noted Wang.

    No one knows for sure how long the current economic contraction might last, but, as in any downturn, organizations will seek to conserve cash, said JFrog CEO Shlomi Ben Haim. DevOps initiatives will continue to be prioritized because otherwise, organizations risk falling far enough behind that they may not be able to ever recover, he added. “DevOps is in a good place,” said Ben Haim.

    In fact, thus far many DevOps companies have yet to see a decline in demand because organizations are investing in automation to reduce their technical debt costs, noted Thomas Krane, managing director for Insight Partners. “It’s a matter of life or death,” he said.

    At the same time, Krane said organizations might want to take a hard look at the profitability of the vendors they are counting on to drive that innovation. Vendors that have been counting on venture capital funding to maintain operations may soon find that money much harder to come by as capital becomes scarce, he noted.

    The core issue will become how quickly returns on investment (ROI) are generated, added Incredibuild CEO Tami Mazel Shachar. “There is going to be a lot more focus on ROI,” she said.

    In the meantime, the debate over what constitutes DevOps continues. Some narrowly define DevOps as a set of development activities that revolve around continuous integration/continuous delivery (CI/CD) platforms. Others definitions of DevOps include everything from application testing to observability and application security. No matter how big the proverbial DevOps tent is defined to be, however, the number of organizations that are embracing DevOps—and now DevSecOps—workflows more deeply only continues to increase.

    The challenge is focusing those efforts on the projects that deliver the most value for the business in the face of executive uncertainty about the future. Of course, nothing quite focuses the mind like an impending crisis; for better or worse, it will require more organizations to honestly assess their current capabilities.

  • Supergraph: One GraphQL Schema to Rule Them All

    Supergraph: One GraphQL Schema to Rule Them All

    GraphQL has been garnering much interest as a way to seamlessly interact with backend services. The query language is a boon for frontend developers, too, as it conveniently allows you to fetch the specific fields you require, thus eliminating the potential overfetching or underfetching concerns of REST APIs. And as GraphQL adoption matures within organizations, there is increasing interest (and investment) in how enterprises can use GraphQL to securely unify their growing catalog of disparate microservices and APIs.

    Using GraphQL as a meta layer could help unite many disparate systems under a single unified schema. This would enable the age-old promise of composability, in which software building blocks are seamlessly pulled together to assemble applications and unique experiences for different client types. However, managing GraphQL at scale can become tricky. And when a schema gets really large, it then may require a schema of its own! This is where the concept of the supergraph comes in.

    I recently met with Geoff Schmidt, Apollo GraphQL CEO, to discover what a supergraph is and how it may help platforms aggregate their backend microservices. According to Schmidt, “Developers want this composition layer for one abstract view of all their services.” Below, we’ll explore the concept of the supergraph and look at some new open source components that may help you enable GraphQL-based composability in your organization.

    Microservices Enable Composability

    First off, what do we mean by composability? Well, composable architecture is intrinsically linked with microservices. You can think of each microservice as a single lego piece that makes up one aspect of an application. For example, Uber uses 4,000 microservices to power its backend. These services span from maps, currency conversions, driver reviews, payments and other components. When combined, they ultimately create the convenience and the sleek user experience that is Uber.

    Historically, software developers were overseeing larger monolithic applications in which a single client was interconnected to a web server, Schmidt explained. On the other hand, microservices tend to be more domain-specific and used in tandem with other microservices. They’re also typically easier to iterate on and faster to ship when compared to monolithic codebases.

    The Need for Aggregation

    As a result of the microservices age, applications typically pull in far more data from various sources. For example, a banking application might loop in a mortgage service, investment service and other data sources to display a combined net worth on a screen. This explosion in microservices has created a “polygon environment” spanning databases and APIs, increasing service complexity, said Schmidt.

    Nowadays, many third-party components must be combined to render an experience. However, supporting this composability can be challenging for developers and backend API teams—not to mention that handwriting a backend-for-frontend could be burdensome. “App developers are slowed down by the need to integrate or compose these backend services,” said Schmidt. “Developers need a way to put all those pieces back together.”

    What is Supergraph?

    Supergraph can be thought of as a graph of graphs. The vision is to have one GraphQL schema and one ingress port to oversee many services. Creating a supergraph is becoming more accessible, too, as more open source projects emerge to enable this paradigm. For example, Apollo recently open sourced some components that can help to build and operate a supergraph. These include Federation, which helps to create a data graph across multiple services, and the Apollo Router, a tool written in Rust that decides how to route queries. Apollo has also open sourced a supergraph demo along with other resources.

    A supergraph architecture is already powering Expedia, Walmart, Netflix, Paypal, the New York Times and other large environments, said Schmidt. For example, Expedia has used a supergraph to combine flights, rental cars and other microservices to create integrated experiences. Hivee, an upstart modern supermarket chain, also uses a supergraph to unite its investment into APIs.

    According to Schmidt, the fundamental benefit is that less time is spent writing integration code which means faster development speed and the ability to quickly pivot your business. “It allows you to change business quickly to meet the needs of your customers.” A supergraph could also enable greater visibility into your API estate, making auditing easier.

    A key benefit of the above components is that they already have a proven track record running at a commercial scale. But outside of the Apollo projects, other groups are attempting to codify a similar GraphQL schema aggregation concept, as well. For example, WunderGraph utilizes GraphQL within a “virtual graph” that acts as a common language to call various underlying APIs.

    Repercussions of ‘One Graph to Rule Them All’

    Schmidt said the hope is that, at the end of the day, this abstraction can contribute to “making the world a little more human-centric.” This is because GraphQL can enable less rigid apps that conform to unique user tastes. But a robust composition layer will be necessary to allow such reconfigurations.

    Of course, as I’ve covered previously, there are significant security hurdles to address when supplying so much power to a single entryway. Increased GraphQL reliance will require forethought into new potential security risks, such as schema introspection and object-level authorization control.

    According to Schmidt, a GraphQL composition layer presents an opportunity to enforce security controls. He defines these as contracts that create access rules for a particular set of users. By declaratively managing GraphQL security, a development team, in essence, could expose a subgraph of the supergraph for a partner to consume. The graph could even be segmented for internal teams.

    A central point of ingress will require authorization rules to protect user privacy and avoid breaking the rule of least privilege. Schmidt also advocates for backend schemas to be built for app developers who understand their needs, instead of precisely mapping logic to business models.

    Supergraph: A Graph of Graphs

    Software is becoming more modular, which has resulted in an explosion of unique microservices and APIs. And we’re now at another tipping point in how software architecture is divided and combined, said Schmidt. He now sees GraphQL as a prime opportunity to create software architectures that call multiple backend services with a single GraphQL query.

    “GraphQL is the composition layer you need to build modern applications,” said Schmidt. “We’re super excited about this. Users have shown that GraphQL is the future. Supergraph is such a powerful technology, and we’re excited to bring this to everybody.”

  • Not Everything That is Necessary Adds Value

    Not Everything That is Necessary Adds Value

    Since the Lean production method for manufacturing arose in the 1930s, organizations everywhere have been seeking ways to apply it to reduce waste and increase productivity. This model has served thousands of companies well, from manufacturing and product design to software development. Yet, one difficulty that comes up when discussing or applying Lean in software development is the debate about what is and isn’t considered value-added work.

    Some people get defensive when certain activities are labeled non-value-add (NVA). Others argue that if a customer expects an activity and is willing to pay for it, it must be value-add (VA). From my perspective, software engineers, business leaders and others must accept the reality that it’s entirely possible for necessary processes to add no tangible value. We must understand the intent of Lean within these classifications. In doing so, we can get past the defensiveness and disagreements and move on to improvement.

    Let’s explore a few examples of NVA activities that are unavoidable—and therefore necessary—to a successful software development value stream:

    • Resolving important defects
    • Rework to meet client specifications (i.e. after clarifying requirements)
    • Project time tracking and billing (i.e. for time and materials projects)
    • Complying with regulatory mandates
    • Testing

    Some customers expect these activities to be performed. Software professionals generally agree that all of these NVA activities can be necessary. Yet many Lean proponents will continue to insist that they are NVA and should be minimized. So, where does that leave us?

    Distilling ‘Value’ to Its Essence

    Regardless of how important or necessary NVA activities might be, from a Lean perspective, unless an activity is adding value to the finished product, it is technically an NVA activity. Testing is an NVA activity. Defect correction is an NVA activity. Complying with regulations, although important to protecting profit margins for the company—and an activity that might incent customers to select your product over your competitor’s due to their reduced risk—is nevertheless a NVA activity.

    This is where we enter the grey area of “necessary but NVA activities that actually add a lot of value.” One prominent example is resolving defects that cannot be postponed. You’re probably shaking your head and thinking, “No way. Resolving defects increases quality which makes the finished software product more valuable to the end user. Therefore, it must be a value-add activity.”

    The answer is actually, “No, it is not.” Why? While the cost of defect resolution may be incorporated into the final price tag of software, there is no line-item charge for it. Most purchasers will not pay extra for defect resolution. They’ll feel that quality software is essential to their project and defect resolution should be included.

    Furthermore, they believe quality should be built-in— designed into the product and the process used to build it. That makes it an NVA activity. It’s necessary to the delivery of quality software but it doesn’t add value in the Lean sense of the term.

    The truth, whether or not business leaders want to acknowledge it, is that NVA activities are built into almost every product or service. When someone goes to pick up a prescription at the pharmacy they are never asked to pay an extra research fee. When someone test drives a car and decides to purchase it, they aren’t charged for the gas they burned during the test drive. Both of those activities were necessary for the final outcome to be satisfactory to everyone, but they added no value to the effort.

    The same is true for successful software delivery. Lean approaches form the foundation for modern software development, but being Lean doesn’t mean that you have eliminated all NVA activities. In fact, quite the contrary.

    Lean suggests that perfection is never achieved. A Lean organization values continuous improvement and is always looking for ways to reduce NVA activities. For all software projects, some elements will always be NVA. The perpetual existence of both value-add and non-value-add are facts of life.

    Optimizing Necessary Activities

    Despite the fact that these activities might be necessary and, therefore, part of the project cost, they don’t have to be excessive. Responsible software professionals and the companies for whom they work will make an extra effort to reduce waste and optimize outcomes in all NVA activities.

    Reducing or eliminating waste is one of the most important tenets of Lean software engineering. Waste can be found everywhere, from too many people working on a project and ineffective communication to an excessive number of manual processes, backlog mismanagement and rework.

    Breaking the Stigma of “Non-Value Add”

    Companies must develop quality software and sell it at a price that pays for the effort. In my experience, the way to do that is by evaluating every activity. Consider whether it is VA or NVA and whether it is essential or non-essential. Then reduce or eliminate the NVA as much as possible, even if it’s essential, and optimize the VA.

    Software professionals should be ready to defend the importance of the many necessary but NVA activities that go into a quality outcome, while remaining unapologetic about calling them what they are—a process, procedure or other activity that adds no value.

  • One Year Out: What Biden’s EO Means for Software Devs

    One Year Out: What Biden’s EO Means for Software Devs

    It has been just over a year since president Biden issued executive order 14028 (EO) to improve the nation’s cybersecurity posture. Despite the Log4j vulnerability and a worldwide increase in ransomware attacks, this EO signaled a major step in improving software security at federal agencies and establishing cybersecurity as a priority for the U.S. government. While the agencies tasked under this EO have made significant gains, it is important for industry to understand just how much progress has been made since its inception and what that progress means to the average producer of software.

    To understand the effects of the EO, it is important to remember that president Biden does not have the authority to order any government agency to purchase specific software, nor does the president have the authority to require any governmental agency to procure specific software. Instead, the EO instructs heads of agencies to perform specific tasks that will ultimately define more stringent cybersecurity requirements to protect government offices. This doesn’t mean the EO solely applies to U.S. government contractors; if your company is anywhere in the software supply chain leading to a U.S. government purchase, then you need to pay attention to the EO and plan accordingly.

    One of the first of those tasks was for the National Institute of Standards and Technology (NIST) to solicit input from the public and private industry surrounding the structure and management of software supply chains. That work resulted in an NIST publication on EO Critical Software in July 2021. That publication helped outline security measures for software use, including applying practices of least privilege, network segmentation and proper configuration. It also helped NIST to frame the Secure Software Development Framework (NIST sp800-218v1.1) (SSDF) published in February, which provides a set of fundamental secure software development practices.

    This guidance, along with the definition of a software bill of materials (SBOM) by NTIA in November and the updated Cyber Security Guidance for Supply Chain Risk Management (NIST sp800-161r1) released in early May now form part of the risk-based framework that OMB instructed agencies to follow.

    What it Means To Be “EO Compliant”

    Before beginning any discussion about EO compliance, it’s important to recognize that until there are contract clauses defined—and those contract clauses are incorporated into contracts—there isn’t anything to comply with. That process is part of the Federal Acquisition Regulation (FAR) and Defense Federal Acquisition Regulation (DFAR) effort, and the proposed clauses haven’t been published yet. Despite this, we do know enough to start preparing for future compliance and creating processes that will allow for EO compliance.

    The first step is to recognize whether your organization is a supplier within a supply chain of a U.S. government agency. In the context of the EO, that would mean any organization who creates, procures or embeds software into a component or assembly that is ultimately bought by a U.S. government agency. This includes open source software, low-code/no-code frameworks and DevSecOps tooling, to name just a few of the scenarios where U.S. government use might not be immediately apparent. 

    With that in mind, any provider of software within a supply chain should be prepared to answer questions about EO compliance if their software can be used in the U.S. government setting. For some, this could mean updating a few processes; for others, it may prompt a much larger set of changes in the development cycle. Those willing to change may be more likely to retain relationships or gain favor with government suppliers.

    How Software Providers Can Be Proactive

    There are three critical steps that can be performed today as part of preparing an organization for future EO compliance requirements. The first thing providers can do is generate a complete SBOM for their software in an NTIA compliance format and be prepared to attest to its accuracy. While it is not yet clear how the U.S. government will expect to receive an SBOM or what attestation format will be required, generating compliant SBOMs is one of the easiest tasks software producers will face as part of a post-EO world.

    Next, providers should baseline existing software development practices with the objective of aligning with the SSDF (NIST sp800-218v1.1). The SSDF defines a set of tasks that NIST views as a minimum requirement to securely create software and manage the software creation process. If the government procurement requirements include an attestation of compliance to the SSDF, then software producers who already know how well-aligned they are to the SSDF will be that much closer to compliance. 

    Lastly, providers must implement controls related to open source governance. While an SBOM helps identify open source use and the SSDF includes tasks related to its use, neither specifically defines how any software producer is expected to govern their use of open source software. Open source software is fundamentally different from commercial software in many ways; the most important differentiator is that it is freely downloadable from the internet. This free access means that creators likely do not know who their consumers are and thus cannot proactively provide updates or security information. Open source governance processes can help to fill that gap.

    Why It is Time to Embrace the EO

    These first steps can help software providers address the initial requirements that have come out of Biden’s EO and those who get a jump on implementation will have a leg up against their competition. Starting now can save providers a major headache in the long run, as federal agencies seek an understanding of how much risk they bear when operating the software you produce. 

    The rapidly changing cybersecurity landscape was a key driver behind Biden’s EO. Threat actors are evolving their tactics to keep pace with improving cybersecurity postures and it is in everyone’s best interest—from the federal government to the private sector—to put an emphasis on security. An important place to start—regardless of where you are in any software supply chain—is by taking the steps necessary to demonstrate that you understand the risks inherent in operating software and are actively working to reduce those risks for your customers.