devopsy.kinsta.cloud

Category: DevOps Practice

  • Kong Enterprise 2.7 Simplifies API Management

    Kong Enterprise 2.7 Simplifies API Management

    Kong Inc. this week advanced its service connectivity platform strategy with an update to Kong Enterprise that makes it simpler to collectively manage groups of application programming interfaces (APIs).

    Michael Heap, director of developer experience for Kong, Inc., said that capability will make it simpler to, for example, assign rate limits to different tiers of APIs.

    In addition, Kong Enterprise version 2.7 adds support for real-time and event-based use cases involving the open source Kafka streaming platform and webhooks. Usage of event-driven architectures is rising as more organizations embrace digital business transformation initiatives that require near-real-time processing versus relying on traditional batch-oriented applications, noted Heap.

    Finally, IT teams can now also securely store secrets such as user names/passwords, API tokens, database credentials and private keys that might be used to access Kong Gateway. An improved user interface for Kong Manager UI makes it simpler to configure the Kong OpenID Connect (OIDC) Plugin for the Kong Gateway.

    Overall, Heap said, the latest update also provides 25% increased throughput and improved latency. In tests run by GigaOM, a third-party research firm, Kong Enterprise 2.7 achieved 52,250 transactions per second (TPS) maximum throughput with a 100% success rate.

    Kong is making a case for a service connectivity platform that enables an IT team to manage APIs at a higher level of abstraction by integrating all Layer 4 through Layer 7 services for both monolithic and microservices-based applications. Rather than having to manage an array of networking services and associated services in isolated silos, that layer of abstraction makes it simpler to manage distributed applications that have dependencies on a wide range of APIs.

    In general, the number of APIs that organizations are using both internally and externally has expanded tremendously over the last several years. The challenge now is finding a way to not only manage and secure all those APIs but also retire them as new services come online. Many APIs are created and simply forgotten about because their developer neglected to inform IT operations of their existence. Those so-called “zombie APIs” then become a cybersecurity liability when cybercriminals discover they can surreptitiously exfiltrate data via those APIs.

    APIs are, of course, an integral element of any software supply chain. But as high-profile security breaches put software supply chain security in the spotlight, it’s only a matter of time before IT teams look for more efficient ways to manage and secure APIs at scale.

    Inevitably, that also means organizations will need to decide how much they want to rely on proxy software, API gateways and service meshes to achieve that goal within the context of a larger service connectivity platform.

    In the meantime, the days when APIs were managed in isolation from the rest of the IT organization are coming to an end. The only thing left to determine is how involved API developers need to be in their ongoing life cycle management.

  • No Matter How Things Change, Have a Plan

    No Matter How Things Change, Have a Plan

    Had enough change yet? It is almost amusing that I and some other tech people had that conversation a decade ago, and since then, nothing has slowed down. Our conclusion was that, for the near future, change would be constant. That conclusion was right; I’d have to ping everyone else to see what they think, but “near future” turned out to be longer than I expected.

    Inevitably, though, change requires taking a breather at times. It appeared that high-tech was finally ready to admit that burning out your staff was not a viable long-term business model, and was slowing down … and then, COVID-19 hit. Now I’m hearing rumblings about going back to non-stop change as if the last couple of years were a vacation and staff is all rested up and ready to replace massive chunks of the infrastructure.

    The reason that change requires intermissions, though, is not 100% about staff and burnout. That only shows up when you’re making a ton of change non-stop. Before staff burnout becomes an issue, recovery and business continuity plans become outdated. At the rate we’ve been running, I’d go so far as to say they are likely useless.

    Yes, all this change has brought us some cool stuff. While we are busier, some of the busywork is far easier, or even non-existent now—but that doesn’t change the fact that you need to breathe. This is a perfect time to go over plans to keep the business on its feet in case of IT catastrophe—or at least some major systems catastrophe. Saying “We’ll just deploy a new version” is cool, but it only works in some scenarios. I touched on this and discussed one case where it doesn’t work in October 2021. But there are a ton more. Every environment is different, but hardware failures have not disappeared and destructive writes still occur, as just two more examples. Your infosec team can give you a few more examples.

    Knowing what you’re going to do when the worst-case scenario happens is huge. And for those who’ve never been through it, knowing before people are stressed and asking you for a timeline will save you a lot of headaches.

    For those who’ve never had a DR or business continuity plan, consider it. At least have a basic DR plan that lists critical systems, things most likely to go wrong and what the steps are to recover it and get things moving again. The process of making such a list will often uncover things that should be done but aren’t—like backups or backup verifications.

    For those with a DR or business continuity plan, I’ll take a wild shot and say, “It’s out of date.” Organizations tend to create them and then forget about them. These plans should involve a bit of each project, so it’s taken care of in bite-sized chunks, but—probably because the first implementation of DR or BC is normally a massive project—it tends to be set aside and revisited every few years. Don’t do that.

    As I’ve said before, you and yours have built the heart of the modern enterprise. Don’t forget to protect it. It doesn’t take much to use some of these sweet new technology advances to put in DR procedures. Tack DR review/updates onto each major initiative, be it a new product or a big change to existing software. And keep rocking it. If you have a say in your organization, consider slowing the pace down for a bit and even updating DR. If you don’t have a say, may your employer be wise enough to do so.

  • 3 Technologies Driving Business Sustainability

    3 Technologies Driving Business Sustainability

    The pandemic highlighted many things, not least of which was the shift in consumer behavior toward further encouraging companies to change their operations and act with sustainability in mind. An overwhelming 96% of businesses said the pandemic shifted their focus to the social component of environmental, social and governance (ESG) strategies. Technology has been a key player in helping corporations quantify and tackle ESG issues in their sectors.

    A recent PwC and WEF report outlining the use of technology to drive large-scale sustainable change looked at 300 cases of emerging technology in relation to achieving global sustainable development goals. The study found 70% of their 169 targets could be enabled by technology applications.

    With the link between sustainability and technology clear to see, here’s where technology and innovative thinking are boosting sustainability in three key industry areas.

    Energy, Utilities & Resources Are on a Sustainable Transition Journey

    With 30% of overall greenhouse gas emissions stemming from power plants, it is not surprising that utility companies are under intense scrutiny and pressure to transition to green energy. Many are actively investing in renewable energies such as wind farms, hydro stations and solar power. “Green steel” is at the center of America’s 2030 greenhouse gas pollution reduction target, and the U.S. already generates around 11.4 million tons of hydrogen per year. All eyes are on these green steel initiatives that are showing that, with the right resources, there is plenty of potential to decarbonize the U.S. energy, utilities and resources sector.

    A Swedish partnership, which includes Europe’s largest iron ore producer and IFS customer LKAB, has delivered the first fossil-free steel in the world. The steel was made with 100% fossil-free hydrogen instead of coal and coke—paving the way for a completely fossil-free value chain for iron and steelmaking.

    As experienced by LKAB, enterprise software can strategically support the shift to a more sustainably focused energy, utilities and resources sector. To thrive, new business collaborations and joint ventures must be agile and able to develop at pace, unencumbered by restrictive enterprise solutions; to achieve both these goals, cloud deployment and full supply chain sustainability is key.

    Manufacturing–Closing the Loop Requires Supply Chain Visibility

    The manufacturing sector is another major industry facing complex challenges—and opportunities—on the path to sustainability. The time is now for manufacturers to drastically change their linear approach of material, manufacture, dispose and move toward a circular economy of reduce, reuse, recycle. This means adopting reverse logistics methods enabling manufacturers to integrate more environmentally friendly practices into their manufacturing processes.

    According to a recent Deloitte op-ed, “Through the use of digital technology, manufacturers may already have a head start in their sustainability journey. In recent years, the implementation of lean processes using digital capabilities has boosted productivity, created safer workplaces and reduced costs.” For example, enterprise resource planning (ERP) software is helping manufacturers to develop and maintain the overall life of a product by using data and tracking of which areas need more sustainable practices. For instance, manufacturers embracing a circular model can rely on ERP software to help them maintain, recondition, recycle and support a product over an extended life cycle.

    And again, the software can incorporate environmental footprint management tools to capture the footprint of their product over its life cycle and present information that can be used for better decision support. By analyzing the percentage of post-consumer waste used in a product, manufacturers can then see where they can maximize the reutilization of components and preempt sustainability challenges.

    Aerospace and Defense—AI Predicting a Cleaner Future

    Every industry has a part to play in reducing carbon emissions, and the aerospace sector is no different, so it’s necessary and right that the industry is taking significant steps toward improved sustainability. Some of the key enabling technologies that will support this are highlighted by Global Data in its Thematic Research on ESG in Aerospace and Defense. The report highlights: “Electric aircraft, hydrogen-powered aircraft, and sustainable aviation fuels (SAFs) are key innovations that will shape the future of air travel. Improving social sustainability is vital for companies seeking to earn government contracts, increasing visibility and improving management throughout the whole supply chain will be vital.”

    From the Silver Spirit to the Spirit of Innovation

    Leading original equipment manufacturers (OEMs) are highlighted in the report for applying innovative thinking to solve industry emissions challenges. Rolls-Royce, for example, has already announced the first flight of its all-electric “Spirit of Innovation” aircraft and has committed that by 2023 all of its Trent family engines will have been proven compatible with 100% SAF.

    The Rolls-Royce Trent, a family of high bypass turbofans produced by Rolls-Royce, has been able to help airline customers automatically update predicted maintenance deadlines for every life-limited component inside their engines by using AI forecasting and digital twins through IFS aviation maintenance software. This forms a key part of the Rolls-Royce Blue Data Thread strategy; a digital information thread connecting every Rolls-Royce-powered aircraft, every airline operation, every maintenance shop and every factory.

    More effective maintenance will also translate into sustainability benefits. As the aviation industry moves toward a greener future, digitalization and predictive maintenance are important elements for the engineering side of the industry. By reducing the need for maintenance interventions, part replacements and overhauls, the use of energy and resources in manufacturing is reduced, and the emissions footprint of part and engine logistics is minimized.

    Turn to Tech to Sustain Green Pledges

    These are just three industries where technology is playing a pivotal role in achieving ESG goals. The case is clear: Sustainability initiatives can be accelerated by here-and-now technology such as IoT, AI, cloud deployments and more, not space age or future–focused solutions. The link between meeting customer demands, fulfilling environmental goals and greater profitability has never been closer. Technology will be a strategic business enabler to achieve all three.

  • The Evolution of Incident Management

    The Evolution of Incident Management

    Have you ever thought about the history of incident management?

    If you’re an SRE, you might be so caught up in the day-to-day work of managing reliability and responding to incidents that you never take time to step back and reflect on the evolution of your role and your responsibilities. And that’s a shame because SREs didn’t invent incident management concepts and strategies on their own.

    On the contrary, the way SREs think about incident response, structure incident management teams and rank the priority of incidents owes much to incident management strategies developed in the offline world decades ago. To understand fully what it means to be an SRE today, you have to appreciate this deep history of incident management and response.

    So, let’s take a look at that history and examine where modern incident response concepts originated.

    Historical Problems in Incident Management

    Societies have always had incidents, of course. Fires, floods, infrastructure breakdowns and similar crises have been happening for millennia.

    For most of history, however, humans lacked an efficient, purposeful way to manage these sorts of incidents. Response efforts were ad hoc, and their effectiveness owed more than a little of their success to sheer luck.

    Particular challenges included:

    • Lack of effective, consistent communication between stakeholders.
    • Varying organizational structures which made it hard to identify leaders, coordinate response efforts and delegate tasks.
    • Inconsistent response strategies.
    • Differing approaches to assessing the priority of incidents.

    Historically, organizations may have been able to handle incidents well enough if the incidents required response from only one, small group. But the more stakeholders involved, the harder it was to respond quickly and effectively.

    Putting Out Fires: The Birth of the ICS

    Things began to change for the better when stakeholders started thinking about better ways to put out fires—literally.

    By the 1960s, fire chiefs in California realized that they were struggling to respond effectively to the wildfires that broke out every summer. Each year brought worse blazes than the last, with more land burned and more buildings lost. The Laguna fire of 1970 brought matters to a head and was the catalyst for a new approach to incident response for fire agencies.

    After assessing what was going wrong, the fire chiefs determined that it wasn’t a lack of equipment or personnel. It was poor coordination among the various firefighting agencies that responded to blazes. Lacking a clear chain of command and a systematic approach to firefighting, the agencies struggled to deploy their resources rapidly and, thus, effectively.

    To fix the problem, California fire chiefs developed what became known as the Incident Command System, or ICS. The ICS defined a hierarchy for incident response with an incident commander at the top. It also defined several categories of incident response processes including operations, planning, logistics and finance. And it established a consistent set of terms that stakeholders can use to describe their actions during incident response, which makes it easier to communicate clearly.

    Although the ICS was initially conceived to fight fires, it became the de facto standard for organizing incident response strategies of all types.

    From ICS to NIMS

    The history of incident response doesn’t end with the ICS. A new chapter began in the early 2000s when the U.S. federal government developed an even more comprehensive approach to incident management called the National Incident Management System, or NIMS.

    NIMS was born in the wake of the September 11, 2001, terrorist attacks, which underlined the importance of efficient communication not just between different agencies of the same type (like fire departments), but of entirely separate organizations. To achieve this, NIMS expanded upon the principles of the ICS.

    In addition to adopting most of the incident command principles and practices included in the ICS, NIMS included standards for coordinating the distribution of resources. It also embraced the concept of the emergency operations center, which is in some ways similar to a network operations center in the digital world.

    In some respects, NIMS resembled a compliance framework (although to be clear, that’s not what it is). It includes fourteen management principles, similar to compliance controls, that organizations must implement to manage incidents using a NIMS approach.

    Incident Management Today

    Obviously, putting out forest fires and responding to terrorist attacks is pretty different from dealing with data center failures or a buggy application deployment. ICS and NIMS weren’t designed for site reliability engineering or IT teams specifically.

    Still, the influence of ICS and NIMS on the way SREs think is clear enough. Terminology like “incident commander” comes from these frameworks. So do concepts like shared accountability for incident response processes and the importance of involving all stakeholders—not just technical teams—in incident response.

    ICS and NIMS may not be acronyms familiar to most SREs. But they should be, because they are the historical sources of the incident management philosophies that form the foundation for SRE work today and offer valuable lessons for any SRE on the job today.

  • Why Developer-First is the Future of AppSec

    Why Developer-First is the Future of AppSec

    DevOps culture and rapid cloud adoption mean developers are shipping code faster than ever and, in many cases, security teams struggle to keep up. To avoid relegating security to afterthought status, organizations must shift left and adopt a developer-first approach to application security (AppSec).

    Organizations that depend on software development need a solution that accomplishes two essential things to adapt and survive: Risk-appropriate security measures and an even distribution of functions across the stack. First, risk-appropriate security measures must be applied to all software before it is delivered or deployed. Second, they must adopt processes that enable security functions to be distributed across the development stack in a way that will not slow down the pace of development.

    Just as the entire development process starts with developers, integrating security should also start with a developer-first approach. Developer-first AppSec is the future; here’s how organizations can evaluate tools that will help them adopt a developer-first approach.

    Why Developer-First is the Future

    Developers outnumber application security engineers by as many as 100 to one, and AppSec functions cannot scale if security practitioners are the only ones responsible for security. This imbalance suggests that organizational leaders must better distribute security ownership across the developer teams that own the software asset.

    As it stands today, many companies expect developers to build and deploy software faster than ever before. Security teams often can not keep pace with software development, and they become a roadblock to software delivery. To meet project development deadlines and their key performance indicators (KPIs), developers tend to leave security teams behind. They do not have the time or the incentive to slow down development because application security tools or processes are slow and cannot keep up.

    Security and developers are at cross-purposes in today’s software development model. They are pseudo-adversaries because AppSec teams know what it takes to make code secure, or at least they know how to find vulnerabilities. And, on the other hand, developers need to write code that works well and meets the sprint’s deadline.

    Friction Between Teams

    This growing problem creates friction between these two teams. It’s not that security teams don’t care about the organization’s need to produce quality software quickly or that developers don’t care about security. It’s just that each team is measured and incentivized to achieve opposing objectives. AppSec programs must create a developer-first approach to building software quickly and securely to combat this growing problem.

    It is not feasible for organizational leaders to provide security engineers with the entire business or environmental context behind software applications. In this sense, AppSec teams are working with limited vision. They may not see how the software fits into the organization’s big picture or understand its priorities.

    With limited contextual understanding, security teams necessarily rely on developers to make decisions about acceptable risks. If left to their own devices to view the world through a security-centric lens, AppSec teams could get bogged down—potentially spending too much time enforcing security measures that do not apply to the task at hand.

    Since developers are building the software and know what the services are designed to do, security engineers must defer to a developer-first approach so that decisions about security issues will align with the business context and acceptable levels of risk.

    Finding a Developer-First AppSec Platform

    Below is a condensed guide to help organization leaders evaluate potential AppSec platforms. These questions will help identify a solution that will enable the organization to build a developer-first security program.

    • Will the solution flood the developers and AppSec team with more and more results, or will this help them fix the essential gaps?
    • Will the solution provide context to help developers focus their limited time on security work that matters, or will it end up wasting time on things that may not even present a risk?
    • Will the solution help build security measures as guardrails to prevent security issues in the first place?
    • Is the solution flexible enough to enable building custom application security checks and policies in the SDLC?
    • Does the solution provide flexible ways of communicating actionable security information directly to developers in real-time within dev tools like source control systems, CI/CD platforms or engineering task management systems?

    There are an overwhelming number of application security solutions on the market today, most of which are designed to create security alerts about every conceivable threat regardless of the business context of the software being developed. More tools are then needed to manage the identified vulnerabilities.

    What This Future Will Look Like

    AppSec teams must recast themselves as security facilitators providing expertise for solving complex challenges and maintaining oversight of the developer teams’ security efforts. Developers should own tactical security tasks, but the AppSec team should continue to be the experts in making risk-based decisions and driving security accountability across the business.

    Inside many organizations, application security is only beginning to become integrated into developer workflows. This integration creates both opportunities and challenges. As organizations strive to make AppSec an enabler that aids developers in creating secure software quickly, developer-first AppSec programs let businesses make their digital transformation journey safer and faster.

  • 4 Ways to Uplevel Your Software Engineering Team

    4 Ways to Uplevel Your Software Engineering Team

    In my 20 years leading software development teams, I’ve witnessed the industry’s continuous growth alongside technology’s evolution. The only thing we know for certain is that the industry will continue to change and winning businesses will be those that build with change in mind, backed by effective, fast-moving software teams.

    This is the year we must focus on fine-tuning our DevOps processes and uplevel our teams, but where do we start?

    Below are four ways you can begin to transform your teams into engineering powerhouses, no matter how big or small or where they are in the world.

    1. Embrace New Delivery Models

    Remember when deployments were a big deal; a highly-anticipated event that often meant late nights? These days, many teams have managed to make deployments a non-event and are deploying any time of day. Those that haven’t adapted risk being left behind. The rate of deployments will only increase, so how teams handle this progression will be a deciding factor for success in an already competitive field.

    In 2022, teams should continuously evaluate their procedures as they push the boundaries of their tech stack. Navigating the complexity of the digital era—from massive datasets and machine learning to networks of third-party services—will force both developers and company leaders to embrace flexible tooling and processes to ultimately refine the risk/innovation tradeoff.

    2. Prioritize People and Culture

    While 2021’s Great Resignation saw many software professionals jumping ship in search of a fresh work environment, in 2022 we expect to see a Great Reshuffle. Realizing their new or current gig still may not be quite the right fit, engineers and developers will start looking for roles that are more in line with their long-term career and personal goals.

    Don’t fear this reshuffle. Instead, recognize it as an opportunity to build a strong and stable team. Be honest about what, exactly, the job entails and the hard and soft skills you’re looking for. Honesty throughout the recruitment process leads to a better match between employer and employee and also contributes to resilient company culture.

    3. Deploy Low-Code Solutions Strategically

    Pressure to get the highest productivity out of software development teams has led to the adoption of no-code and low-code solutions. But that means these tools are being used predominantly by people who already know how to code. The folks with big ideas who don’t actually want to be programmers remain unserved and untapped.

    Expect this disparity to soon lead to a split in the category of no-code and low-code solutions—those built specifically for optimizing developer teams, and those that can serve everyday creators. To really get the most out of your team, keep an eye on the low-code space and ensure the solution you use is the one that’s actually best suited for your goals.

    4. Build With Change Validation in Mind

    The growing adoption of cloud storage, service-oriented architectures, third-party API-based services and open source code (to name a few) makes modern software development monumentally complex.

    A way to manage this complexity is by pulling our focus away from the application itself and onto myriad sources of change that affect the application—a concept we can think of as change validation.

    Ultimately, change validation builds upon tried-and-true software best practices such as continuous integration, continuous delivery and release orchestration. Cloud-native architectures can be effective and scalable, but you need to have the right tools and systems in place to validate changes to your code at every step.

    In the past, the general consensus was that you shouldn’t test in production; you should just release and wait for the bug reports to tell you what’s wrong. But in the world of extensive software supply chains and cloud-native architectures, testing in production is the only way to truly know whether changes to your code are working as intended before releasing software to customers.

    In the new year, software developers will be of critical importance as organizations continue to expand on digital services and projects. Embracing new methods of software delivery, prioritizing people and culture and keeping an eye on how to best leverage automation tools like no-code/low-code and change validation will all help to transform your team for the better in 2022. This forward-looking approach and a willingness to reassess and pivot guarantees that your software engineering team will remain agile amidst a rapidly changing tech landscape.

  • Trends in the API Industry

    Trends in the API Industry

    The application programming interface (API) economy is chugging along full steam ahead. The API management market alone is expected to expand 35% by 2025, supported by the sheer number of web APIs coming to market. APIs have become ubiquitous across microservices architectures, public product initiatives, SaaS platform offerings, IoT and partner-partner integrations.

    The industry has proliferated and continues to change, introducing new API use cases across all industries. This ubiquity creates a heightened need for an API program to maintain a quality developer experience and remain competitive. There are also different styles and specification options on the market, meaning designing the right API strategy is a moving target. And, amid peaking cyberattacks, developers now have a strong imperative to retain high security and reliability for these integration points.

    I recently met with the CEO at Stoplight, Steve Rodda, to discuss the above trends and other forces pushing the API industry forward in 2022. Below, we’ll dive into these trends to see how they affect API strategies and what developers need to know to stay on top of their applications.

    Non-Software Companies Embrace APIs

    As software eats the world, more companies are becoming software companies. And, an API strategy is part and parcel of this digital transformation. A big trend that Rodda recognizes is increased API strategies among traditionally non-software companies.

    For example, Rodda explained how a large beverage manufacturer evolved to adopt APIs company-wide to better use and scale their data. Standardizing the API development and design process helped avoid the “rat’s nest” of custom code, said Rodda. “APIs are no longer a byproduct; they’re a design artifact,” he said.

    APIs are no longer reserved for startup cloud-native unicorns like Stripe or Twilio, either. We now see many industries and sectors like supply chain management, health care, shipping, built environments and mainframe modernization adopting API approaches. The financial services sector is especially keen to open up APIs as open banking is being driven by regional regulation or market pressures.

    A Rise in Internal API-First Adoption

    ProgrammableWeb, the most comprehensive API directory, lists over 24,000 APIs at the time of writing. There’s no doubt that public-facing APIs are very well documented. But this is only a sliver of total API adoption.

    The 2021 Postman State of API report found that only 15% of APIs are publicly available. Most APIs are either partner-facing (27%) or private (58%), according to the report. In fact, the most popular use case for APIs is integration between internal applications, programs or systems. Along with the growth of internal API use, API-first thinking is gaining mind share. Postman defined API-first as “defining and designing APIs and underlying schema before developing dependent APIs, applications or integrations.”

    Internal use cases are less frequently discussed but are pervasive for large enterprises, said Rodda. Whereas in the past, development teams paid less attention to style guides and documentation for internal services, he now notices that these practices are shifting. The zero-trust approach is influencing teams to take more care in defining and standardizing internal APIs as if they’re external-facing. This also eases consumption. “You need to take care of the folks next door to you and treat them with just as much respect,” said Rodda.

    The Growing Need for Robust API Security

    APIs have a security problem. Many don’t handle authorization correctly and expose far too much information. A hacker can often escalate their privileges or simply swap a different user ID into an API call to return loads of sensitive data or even make changes to the data. Many HTTP API endpoints that are intended to be private really aren’t. As a result, OWASP lists broken object-level authorization as a top API vulnerability.

    In recent years, we’ve seen what can happen when APIs are improperly configured. For example, a Facebook API lacked an authorization check for unlisted posts, allowing a client to post on any user’s behalf. A similar authorization hiccup occurred with Peleton that allowed hackers to alter any user’s back-end account. APIs constantly work with sensitive data and must carefully navigate the various data privacy regulations around the globe.

    According to Rodda, a design-first mindset is vital to ward off security woes early in the API life cycle. This means deciding on a structure with a common design and choosing appropriate style guides well before coding. “Good documentation, good design guides and good discipline around building something with a cross-functional nature will increase security and scalability,” said Rodda. When you know what’s going on, you have more control and things are inherently more secure, he added.

    OpenAPI Carries The Day

    The OpenAPI specification, formerly known as Swagger, is an industry-standard specification for describing REST web APIs. OpenAPI can help direct your API’s design and development. OpenAPI tooling can also help generate useful documentation, sandboxes and SDKs, making it a valuable specification for creating interoperability between partners.

    “OpenAPI is going to carry the day for a while,” said Rodda. The OpenAPI Initiative has gotten the support of big names in the tech industry. Yet, Rodda estimated only 40% of companies have adopted OpenAPI in production. Rodda said he believes tooling will make it easier for more groups to maintain OpenAPI adoption across their organization, reducing the redundancy of writing “yet another YAML file.”

    REST is still by far the most-adopted API design style—59.7% of developers use REST for production APIs, according to RapidAPI’s State of APIs Developer Survey 2021 report. Yet, asynchronous event-driven communication protocols are gaining traction, and those protocols tend to prefer alternative description formats like AsyncAPI. Websockets, gRPC and GraphQL are other options consistently used by a significant percentage of API developers.

    Developer Experience Matches User Experience

    Another major trend is the rising importance of developer experience (DX). DX is akin to user experience but is all about increasing usability for developer consumers and improving their ongoing relationship with software-as-a-service. “DX is as big a deal as UI/UX these days, if not bigger,” explained Rodda. “Developer experience directly translates into efficiency and reusability.”

    In the context of APIs, increased consideration of developer experience means reducing the onboarding effort and maintaining more reliable connections. For example, users will likely look to other solutions if a third-party API has poor uptime and routinely introduces a breaking change. Better DX likely will also equate to increased abstraction layers and more code generation. Rodda pointed to GitHub’s CoPilot as an example of the use of AI and automation in the developer-of-tomorrow’s workflow.

    “We’ve evolved as a developer society,” said Rodda. Just as consumers expect high-quality real-time applications, developers expect highly performant APIs. To help get there, one increasingly popular philosophy is the API-as-a-product perspective. “If you treat it all as a product, you’re building it with the same standards and quality that you would share externally,” he explains. “Then, there’s no attention to detail that goes missing.”

    Final Thoughts: The Design-First Mentality

    More industries are utilizing APIs than ever before, and APIs are seeping into traditionally non-technical companies to aid their internal integration efforts. But data privacy is a pressing concern when opening up data, requiring careful measures. Taking a design-first approach with standards like OpenAPI could help organizations stay alert and ensure consistency across their portfolio of services.

    There are other trends at work in the API economy, too. For example, one interesting Web3 initiative is an attempt to combine the world of blockchain and APIs by enabling on-chain smart contracts to interact with traditional HTTP APIs. There is also a lot of development activity around GraphQL, which could act as a command line for consuming multiple APIs, thus making integration easier.

    Rodda said the biggest takeaway is that APIs should no longer be treated as byproducts. He compared it to a construction project: When building a house, you must start with a blueprint before installing the foundation, wall, roof or electrical system. Similarly, APIs require solid forethought to ensure stability and scalability.

  • Taking a DevSecOps Approach to API Security

    Taking a DevSecOps Approach to API Security

    An application programming interface (API) is a data transfer approach that enables services within an application to talk to other applications (or other services within a system). Essentially, it enables Service A to talk to Service B in a uniform way. Companies benefit from APIs on a daily basis without even thinking about them. APIs are a way for companies to gain market share from competitors and monetize applications in new and exciting ways. For example, every time someone signs on to their favorite social media platform or shops on Amazon, the application is utilizing APIs to fetch and update the data with which they are interacting.

    Discovering and securing APIs is a never-ending battle for IT teams across all industries. APIs, for all their benefits, open new attack surfaces targeting a company’s data via vulnerabilities and exposures. In Gartner’s recent report, API Security: What You Need to Do to Protect Your APIs, the analysts estimated that for 2021, 90% of web-enabled applications will have more surface area for attack in the form of exposed APIs rather than the user interface (UI), up from 40% in 2019. This turned out to be accurate.

    Traditional Approaches to API Security

    Traditionally, APIs are protected by enterprise API gateways and content delivery networks (CDNs). Although these approaches hedge against most brute force and denial-of-service (DoS) attacks, a more nuanced and sophisticated attack can breach these protections. The traditional approaches to API security are littered with limitations.

    Companies typically use two types of APIs – customer-app-facing APIs also called “north-south APIs” and internal APIs called “east-west APIs.” The external type is exposed to all public internet traffic. External developers can make requests and receive responses to these customer-facing APIs and take advantage of the functionality and data of an application while bypassing the user interface (UI). Internal APIs, however, are exposed only to intra-application traffic. For example, the cart service may call the user service via an internal API during the checkout process of an e-commerce application.

    Customer-facing APIs tend to be a bit more stable, visible, and targeted at a developer audience. The largest challenge of these north-south APIs is ensuring that this layer is secure every second of every day. This open and accessible API is designed to be utilized by developers outside the publisher’s organization. The goal is to leverage a community of technical audiences and increase usage of the organization’s data and services. Occasionally API publishers encourage developers to create applications that expand on the core business.

    While internal developers may call north-south APIs for their application development, the more common east-west API calls between services often drive much of the incremental feature development and new innovations. These APIs may or may not be accessible by developers outside the publishing organization. However, increasing numbers of east-west APIs are native in the public cloud so the attack surface can easily be exposed publicly. Further, changes to these east-west APIs are made constantly — as fast as a company’s DevOps and CI/CD practices allow. Unfortunately, this speed of change makes mistakes, errors, and security oversights more likely. These APIs and changes are less visible, which leaves companies at risk of discovering vulnerabilities only after a hacker has breached private data.

    Security Breaches of APIs

    Data leaks through all APIs, but companies can’t protect what they don’t know. The moment APIs are exposed on the internet, they create attack vectors for hackers to extract data. If some of the largest companies in the world have insecurities throughout their codebase of APIs and services, we can bet every other company does too.

    Security breaches of APIs are so dominant because APIs are such a ubiquitous method of passing information. Data breaches come in many forms, but they almost always affect company revenue and reputation. New API breaches and vulnerabilities are discovered almost daily. Capital One, Microsoft, T-Mobile, Symantec, McDonald’s, Instagram, Salesforce.com, and Venmo have all experienced major API breaches in the past few years.

    The DevSecOps team or security specialists should make ongoing risk-based decisions on when certain issues should be mitigated, and where in the CI/CD pipeline those concerns should be tested. However, in key scenarios, active protection is required to prevent a security incident from occurring or escalating. IT teams need to use tools that add this layer of protection without requiring humans to be involved.

    The traditional approaches to API security, although helpful at reducing the attack surface, are too slow to keep up with the ever-evolving tactics of bad actors. Only with a clear and full-stack view of an application’s security can IT manage risk and enforce appropriate security policies. Without better telemetry and observability, every security decision will be a shot in the dark and critical holes in API security will be missed.

    Consistently and Constantly Analyze

    Security processes and tooling should constantly analyze the cloud environments, API gateways, logs, web and mobile applications, as well as source code for changes that might create vulnerabilities. Once IT is able to identify the changes to their system, they can confirm that authentication, authorization, encryption, access and verification meet the standards set for the team.

    Active protection without human intervention is the only way to achieve real-time enforcement of security policies and protect against attacks as they occur. Ideally, a security solution should automatically discover and inspect for API security vulnerabilities, while humans analyze the situational risk and prioritize the work.

    With active protection in place, when a security incident occurs, IT will be able to rapidly leverage critical information to appropriately identify the components of the system affected and the contributing factors that led to the event, and protect the data.

  • It is Time to Secure Git

    It is Time to Secure Git

    At this point, we’ve got a ton of experience with the bits of Git that we use. And locking down Git is well-documented. Okay, it is documented; we can say that, at least. Interestingly, much of the ‘how to secure Git’ information out there is actually ‘how to keep critical information out of Git,’ and that is the problem. ‘Critical information’ always includes warnings to “not put configuration information into Git. Ever.” And that has been the default way to lock down Git for nearly its entire existence.

    Then along comes GitOps. What is its purpose, in a nutshell? To put that critical information into Git. So we have been waltzing along; only a fraction of us actually locking down our implementation because we were making sure the data in Git, while valuable, was not full of bits of information that would be useful in compromising systems. But now it will be. In fact, in GitOps, nearly everything is one of those bits of information useful to attackers.

    All of which means that it is time to get serious about Git security. Not content, but actual Git security. I won’t go crazy with links to lockdown documents here—it is a vastly different process to lock down a local Git repository versus a remote one and it is drastically different when you’re locking down a service like GitHub or GitLab (actually, some of the work is done for you with a SaaS vendor) … so, you’ll have to look it up yourself, based on your Git implementation. But there are documents out there that walk you through it; you’ll just have to make sure you find the ones that say, “How to lock down Git repositories” and not “How to keep privileged data out of Git repositories.”

    But whatever you do, stop putting it off. Now, if a neer-do-well gets into your repository, it won’t just be source code for various apps that are leaked—and that is certainly bad enough, even if your organization is not a software organization—it will be infrastructure information that can be used and abused. So make certain that information is protected in every possible way. Point security at Git and tell them, “We know you are insanely busy, but this is the most important thing to protect if we are going to implement GitOps.” Because it quite literally is. If database configuration, network configs and possibly even login info are to be stored in Git, locking it down (both local and remote copies) is imperative. You wouldn’t leave that info in plain text on a centralized data store and count on existing protections. So don’t do the equivalent with Git.

    If GitOps isn’t in your immediate future, that’s still your source code full of vulnerability advertisements out there, so at least ask your security team to give your Git install/policies/config a review. Even as a developer, I am less worked up about source code repositories than configuration repositories. There are several reasons for that, but the big one is you all. The bulk of organizations just don’t seem that worked up about source code repository security, but that changes when operations is asked about the list of holes in the firewall being moved into Git—and being configurable from Git (as just one example).

    So, keep kicking it! You all are making, delivering and securing a metric ton of software, and the complexity of our environments did not decrease after the remote work wave hit. Yet, you are still rocking it. May you have enough staff to do the job and applicants that come looking to work with you over competitors. And keep showing the world that software is manageable. But secure your Git.

  • Continuous Security: The Next Evolution of CI/CD

    Continuous Security: The Next Evolution of CI/CD

    Following a wave of high-profile cyberattacks and the White House’s release of the executive order on improving the nation’s cybersecurity, how to build a successful cybersecurity program has never been so hotly debated as it is now. From SolarWinds to the Colonial Pipeline attacks, these events demonstrate that defensive measures alone cannot mitigate cybersecurity risk, and any cybersecurity program must begin where nine out of 10 breaches begin—the code. 

    The adoption of CI/CD in recent years as an extension of Agile and DevOps has enabled organizations to embrace digital transformation and ensure code is always being delivered that matches the most current business needs. Unfortunately, this has further siloed security as processes failed to keep pace. While there are a number of point solutions to address the ever-expanding domain that encompasses application security—from traditional pentesting and vulnerability scanners to monitoring of the individual components of the DevOps toolchain like containers—too many tools results in a DevSecOps “hairball” that leaves organizations inundated with data, yet without actionable information. 

    Moving Beyond Secure DevOps

    As organizations continue to evolve their delivery processes, security has found its role in secure DevOps (SecDevOps) programs to ensure the execution of security processes at every step of the software development life cycle (SLDC). By continually managing security practices, policies and debt in existing pipelines, this approach ensures that all stakeholders—from the C-suite to the developers and AppSec managers—have the information they need at every step of development to share responsibility in delivering secure software.

    However, these programs, while a good starting point, have left security requirements and checks in PDFs, Excel documents, and emails failing to capture the same benefits of security integration into the SDLC that Dev and Ops have commanded. Without SecDevOps orchestration, the information often lags the pipeline, creating new bottlenecks and uncertainty. SecDevOps orchestration gives security and development teams the confidence to know they’re following the right policies and eliminates the manual work that creates drag on the SDLC. With the automation of the application security process, enterprises get consistency and insight into their program that allows their focus to stay on shipping code while knowing it meets their organizational security standards. 

    Adding Continuous Security

    With CI/CD, organizations are able to rapidly meet the most current needs of the business as they rapidly evolve, but without a continuous approach to security as well, once again, security is siloed off. Organizations must be able to adapt their security requirements for changes both internal (changing databases, different software versions, etc.) and external (compliance requirements, changing threat landscape, etc). We need to take CI/CD one step further and also have security integrated continuously. 

    By extension, continuous security (CI/CD/CS) is the philosophy of continuously shipping software that meets the most current security standards for the business, accounting for internal and external change throughout the SDLC. 

    To effectively adopt a CI/CD/CS, organizations must focus on three key principles:

    • There is no perfect code, therefore there is no perfect security—Good application security manages cyber risk in line with overall business strategy. When you have the ability to accept risk within the risk tolerance of the businesses, you know the right times to stop, and the right times to carry on because other controls are in place. Don’t let perfection be the enemy of the shipped. 
    • Bite-sized application security—DevOps isn’t about moving fast and breaking things, it’s about moving efficiently and fixing things at the right time. Deliver the right application security information at the right time to the stakeholder responsible for executing it. This ensures better collaboration so stakeholders know where, when and with whom to direct their attention. 
    • Micro-feedback loops—Leverage orchestration to get real-time feedback on policy compliance before it creates bottlenecks down the line. This enables you to respond to changes both internal and external as quickly as possible, creating an iterative cycle of information for future decision-making. 

    By continually managing security practices, policies, and debt in existing CI/CD pipelines, this approach allows a scalable application security program to be deployed in any SDLC so it can continually evolve to always be in lockstep with today’s business.  

    Different organizations have different risks they need to account for, which means security must be aligned to business strategies and priorities in order to dynamically respond. With end-to-end integration in the SDLC, continuous security supports CI/CD to improve productivity and speed time-to-market, while reducing the risks that might impact a particular business. Software is inherently impermanent and organizations need to be able to continuously balance security, technical and business priorities to ensure they are maintaining their focus on what matters most: Delivering value to customers and shareholders.