devopsy.kinsta.cloud

Category: IT as Code

2023 Application Security Budgets on the Rise

A survey of 500 DevSecOps professionals in the U.S. found nearly three-quarters (73%) of organizations plan to increase investment in application security in 2023.

The survey, conducted by Wakefield Research on behalf of Invicti, a provider of dynamic application security testing (DAST) tools, also found 97% of DevSecOps teams said they ignored a real vulnerability at least once a month because they assumed it was a false positive.

Invicti CTO and head of security research Frank Catucci said that while it is apparent organizations are under pressure to improve the security of their software supply chains, the tools and processes used to discover vulnerabilities need to be revisited at a time when the security technical debt accrued in production environments is already massive.

Many DevOps teams have routinely shipped code with known vulnerabilities for years, noted Catucci. They are not only under pressure to improve the security of new applications but also remediate applications with known vulnerabilities already running in production environments, he added.

Cybersecurity teams have, of course, been identifying those vulnerabilities for years. The challenge is that the long list of vulnerabilities cybersecurity teams provide to DevSecOps teams tends to lack any context. As such, it becomes impossible for developers to prioritize their remediation efforts based on the actual severity of the vulnerabilities found. DAST tools help address that issue because they provide insights into vulnerabilities in applications already running in a production environment.

Application security, of course, has historically been problematic because many developers assume cybersecurity teams are securing the environments where applications are deployed. Most cybersecurity teams, however, allocate their budgets to tools and platforms they control and manage. Most of those tools and platforms are focused on security operations tasks that tend to have more to do with securing infrastructure rather than applications. The assumption is application development teams are responsible for securing the software that runs on those platforms. That disconnect is now finally being addressed as responsibility for application security shifts left to become an integral part of DevOps workflows.

The Invicti survey suggested that application security budget allocations are now catching up with that transition. In fact, the Invicti survey found that 100% of DevSecOps professionals are tracking the return on investment (ROI) on the application security tools and platforms they employ. Of course, measuring the effectiveness of any cybersecurity tool or platform has always been a challenge. It’s never quite clear whether a breach didn’t occur because a tool or platform was present or if it didn’t happen because of sheer luck and happenstance.

Regardless of the ROI achieved, however, it’s clear that cybercriminals are increasingly targeting software supply chains. The recent executive order issued by the Biden administration requiring federal agencies to review the security of their software supply chains got the attention of traditional enterprise IT organizations, as well. As such, the overall state of application security should steadily improve in the months and years ahead, as more funding is allocated to prevent vulnerabilities from finding their way into production environments in the first place.

November 7, 2022
Cloud Disaster Recovery Best Practices

It’s increasingly common for companies in all sectors to use the cloud to store their data. The cloud provides scalability, security and flexibility that was often inaccessible to businesses only a few years ago. But just like any other technology, it has its limits.

What happens if a severe thunderstorm knocks out power to a data center or if an employee accidentally deletes critical files? These are the types of scenarios that, however unlikely, can still happen and cause significant disruptions to a company if they’re not prepared.

That’s where cloud disaster recovery comes in. In this article, we’ll discuss why cloud disaster recovery is critical for businesses and the different strategies you can implement to ensure your data is always safe and accessible.

What Is Cloud Disaster Recovery?

Cloud disaster recovery (CDR) is a strategy that helps businesses keep their data safe in the event of an unforeseen disaster. This can be anything from a natural disaster like a flood or earthquake to a man-made disaster like a power outage, fire or cyberattack.

There are many different cloud disaster recovery strategies that businesses can implement, but the most important thing is to have a plan in place so that you know what to do if and when something goes wrong.

One Company’s Story of Cloud Impact: OVHCloud

Before providing strategies, we wanted to give you a real-life example of a cloud disaster that impacted multiple businesses, big and small.

In 2021, OVHCloud, one of the world’s largest cloud service providers, suffered a catastrophic fire at one of its data centers in Strasbourg, France. The fire destroyed the facility, causing widespread damage and leaving many businesses without access to their critical data.

In the aftermath of the fire, it quickly became apparent that OVHCloud did not have a solid cloud disaster recovery plan. As a result, many businesses were left scrambling to find alternative solutions for their data storage and backup needs.

The moral of the story is that even the biggest and most well-known companies can be caught off guard by a disaster. This is why it’s so important for businesses of all sizes to have a cloud disaster recovery plan.

Now that we’ve seen the importance of cloud disaster recovery, let’s look at strategies you can implement to keep your data safe.

Cloud Disaster Recovery Strategies

When discussing cloud disaster recovery strategies, many options are available, but not all of them will be right for every business. The key is to find the strategy or combination of strategies that work best for you and your company.

Here are some of the most common cloud disaster recovery strategies:

1. Know Your Infrastructure

The first step in any cloud disaster recovery strategy is to understand your current infrastructure and what assets and data you have. Your assets can include everything from physical servers and hard drives to cloud-based applications and data.

Do the homework necessary to understand what you have and where it’s located. For example, take inventory of all of your assets and determine which ones are critical to your business operations.

Once you know what you have, you can start to develop a plan for how to protect it. Yes, this may take some time, but it’s an essential step in protecting your data.

2. Conduct a Business Analysis

Data breaches within the cloud can come in many different forms. From unexpected data loss to malicious cyberattacks, it’s important to understand the different ways your data could be compromised. This is where conducting a business impact analysis comes in.

A business impact analysis (BIA) is a process that focuses on identifying and evaluating the potential risks to your business. Rather than focusing on the causes of the breakdown, a BIA focuses on the potential impact of the disruption. The impact can include things like loss of income, damage to reputation and compliance issues.

By conducting a BIA, you can better understand the risks your business faces and what steps to take to protect against them. For example, using endpoint security vendors can help protect your data by preventing attacks on endpoints on or off the network.

3. Draft a Disaster Recovery Plan Based on RPO and RTO

Once you’ve conducted a BIA and clearly understand the risks your business faces, you can start to draft a disaster recovery plan, specifically around the recovery point objective (RPO) and recovery time objective (RTO).

Your RPO measures how much data is lost during a disruption, while your RTO measures how long it takes to recover from it. By understanding these two factors, you can start putting together a plan that meets the specific needs of your business.

It’s important to note that your RPO and RTO will likely differ based on the type of data you’re working with. For example, if you’re working with data that can be easily recreated, your RPO may be relatively low. However, if you’re working with mission-critical data that can’t be easily replaced, your RPO will be much higher. The same is true for RTO.

Regardless, you want to ensure that your disaster recovery plan is based on your specific RPO and RTO so you can recover from a disruption promptly and with minimal data losses.

4. Have a Strong Cloud Backup Solution

No matter what cloud disaster recovery strategy you implement, it’s essential to have a strong backup solution in place. It will ensure that you can quickly pivot to a different strategy and dodge the hefty price tag that often comes with data loss and encrypted files when there’s no backup.

There are several different backup solutions available, so you must find one that meets the specific needs of your business based on the type of data you have and how often it changes.

5. Test Out Your Disaster Recovery Plan Regularly

Once you have your disaster recovery plan in place, it’s important to test it out regularly. Testing will ensure that your plan works as intended and that you can recover from a disruption quickly. Things to test for include data backups, file restores and application availability.

You should also involve your entire team in the testing process so everyone knows what to do in the event of a disruption. Look for collaboration software that comes with important tools such as chat, video conferencing and task management so your team can easily communicate and work together, even when they’re not in the same place.

Final Thoughts

There you have it! These five cloud disaster recovery strategies can protect your business from data loss and keep your operations running smoothly. We suggest starting this process as soon as possible so you can be well-prepared for whatever comes your way.

November 4, 2022
Momento Launches Elastic Cloud Caching Service

Momento this week emerged from stealth to launch an elastic Serverless Cache platform that promises to improve the performance of applications running on databases deployed in the cloud while simultaneously reducing costs.

Fresh from raising $15 million in seed funding, Momento CEO and co-founder Khawaja Shams said Serverless Cache gives IT teams access to a serverless computing framework for accessing cache memory that can be used to improve the interactivity of applications.

Cache is, of course, already widely employed to improve the performance of applications running on databases in the cloud. However, organizations today are required to provision excess cache memory to address performance workload peaks. That approach, over time, conspires to increase the total cost of cloud computing, he noted.

A serverless cache makes it possible to more easily share an elastic pool of memory that can be invoked in seconds via an application programming interface (API) that is itself invoked by adding five lines of code to an application. The Momento cache service can then handle millions of transactions per second that can be spread across multiple applications, said Shams.

The Momento Serverless Cache service also automatically manages hot-keys, maintains high cache hit rates and keeps tail latencies low.

Organizations that are already using Momento on either the Amazon Web Services (AWS) or Google Cloud Platform (GCP) include CBS, NTT Docomo and Wyze Labs, Shams said.

In general, there’s a lot more scrutiny of cloud costs in the wake of the economic downturn, noted Shams. More IT teams are starting to take note of the fact that various cloud-native platforms enable them to more efficiently consume cloud resources, he added.

The simple truth is that far too many organizations are managing cloud resources in much the same way they managed on-premises IT environments. Capacity is being dedicated to virtual machines to ensure application availability with even less regard for cost because the perception is that the cloud makes it easy to throw hardware resources at any issue. The challenge is the bill for those cloud resources tends to add up at the end of every month. Cloud database services, in fact, are among the most expensive to consume, noted Shams.

It’s not clear how much organizations will optimize the consumption of cloud resources in the weeks and months ahead, but it’s clear more supervision is going to be required. Organizations have historically let developers provision resources in the name of agility with little to no regard for cost. Now that finance teams are looking to, at the very least, make sure cloud resources are optimally consumed, there will undoubtedly be more reviews of cloud spending patterns.

In the meantime, many organizations may also decide to accelerate the rate at which they are embracing cloud-native technologies to optimize that spending. One of the more compelling attributes of Kubernetes clusters and serverless computing is they make it easier to scale compute resources up and down as required to eliminate the need to overprovision cloud infrastructure. The challenge, of course, is that the cost of acquiring and mastering those technologies remains significant.

November 3, 2022
Gitpod Looks to Drive Application Development Into the Cloud

Gitpod today revealed it will add an application programming interface (API) to make cloud development environments (CDEs) more extensible. Gitpod also said Johannes Landgraf assumed the role of single CEO for Gitpod, as the previous co-CEO, Sven Efftinge, becomes the company’s first technical fellow.

Fresh from raising an additional $25 million in funding, Gitpod’s Landgraf said that API will make it easier to build plug-ins for CDEs. In time, Landgraf said, CDEs will become as accessible as any development environment running on a local desktop.

Software engineers typically waste five hours a week maintaining application environments, noted Landgraf. Via an open source development platform, Gitpod automates the provisioning of secure workspaces in the cloud that provide the added benefit of making it easier for multiple developers to collaborate, he added.

Capabilities added to the GitPod product roadmap include dramatically faster startup times, improved resiliency and a Gitpod Cloud offering for larger companies as well as a preview environment and workflows that foster collaboration. Gitpod also announced it passed a SOC2 Type II security audit.

Today, the Gitpod platform is being used by more than 750,000 developers at organizations such as Shopify, Stripe and Slack, noted Landgraf.

One of the longstanding issues that has always been problematic when building software is that code that runs on a local desktop doesn’t always work when deployed in a production environment. The Gitpod API will make it simpler to spin up various platforms and tools whenever a developer accesses a CDE. The goal is to make it possible to more closely replicate the production environments on which developers will ultimately deploy their applications, noted Landgraf.

In addition, a CDE should reduce the amount of data that developers routinely move between laptops and cloud computing environments as they build more complex applications, he added.

In the wake of the economic downturn, there is a lot more focus on developer productivity these days, especially as organizations look to accelerate their of digital business transformations. DevOps teams are also keen to find ways to centrally manage developer experience at a time when many of those developers continue to work from home, said Landgraf.

It’s not clear to what degree CDE will replace integrated development environments (IDEs) running on a local machine, but all the major cloud service providers are encouraging developers to build applications in the cloud where their applications will run. The challenge is that many of those offerings tend to lock developers into a specific cloud platform, noted Landgraf. Most developers today are building applications that need to be deployed across multiple clouds, he added.

One way or another, software development is increasingly shifting to the cloud. Most organizations will likely try to find a balance between the amount of code developed on a local machine that developers can just fire up when the mood strikes and the amount of code developed in the cloud. The most immediate challenge is to make sure the CDE experience is every bit as good as the existing local IDE.

November 3, 2022
For Engineers, Meetings Waste Time and Money

Meetings can be the lifeblood of any organization, allowing coworkers to check in with one another, exchange ideas and solve problems. But, for engineers moving up the career ladder, the mounting number of meetings expected of engineering managers can end up being a distraction that does more harm than good.

Research from Clockwise recently examined data from more than 1.5 million meetings over the course of a year involving more than 80,000 software engineers at more than 5,000 companies around the world. Our analysis, which aggregated and anonymized the information, found that large and growing companies in particular are putting themselves at a competitive disadvantage by distracting some of their most valuable talent from doing important work.

Engineers Spending More Time in Meetings

The 2022 Engineering Meeting Benchmarks report showed that as software engineers move into management and spend significantly more time in meetings, they lose more than nine hours a week of what the report referred to as focus time—uninterrupted blocks of at least two hours to focus on deep work.

That loss comes at a cost that can erode an organization’s bottom line. Engineering managers overwhelmingly say that focus time makes them and their teams faster and more productive, according to a related global survey of about 150 of them. Perhaps even more importantly, 76% traced a direct path from more focus time to more revenue.

And as companies grow in size, so does the meeting “coordination tax.” In the hotly competitive tech world, that can put larger companies at a disadvantage compared to their smaller, nimbler rivals. Engineers at smaller companies have significantly more focus time—nearly six more hours per week–and spend three fewer hours in meetings than their counterparts at large companies.

The Pressure of Meetings

We all have our complaints about the seemingly endless proliferation of meetings in modern business life, and many other kinds of professionals certainly need uninterrupted time to be creative. But these pressures are especially acute and costly for engineers. They are often the most expensive part of a team’s budget, and the consequences of diminished time for deep work can be dire. A single misplaced character in a line of code, for instance, can result in a massive bug affecting an entire organization. In 2012, for example, a programming oversight caused Knight Capital Group to execute a series of erroneous automatic trades, resulting in a loss of $440 million in 45 minutes—and a $12 million fine from the Securities and Exchange Commission (SEC). More recently, a few missing characters in a programming update shut down Skyscanner, a travel search engine and booking platform, for more than four hours.

Leaders need to be aware of the burden that they put on their teams with well-meaning but less-than-useful meetings. The engineers in the Clockwise analysis averaged 19.6 focus hours each week compared with 10.9 hours in meetings and 6.3 hours between them, something we call “fragmented time.” As they move into management, their meeting time soars to 17.9 hours while their weekly focus time plummets to 10.4 hours.

And those averages don’t tell the whole story–there’s a very wide distribution depending on the organization. At some distracted businesses, engineers are clocking in with fewer than 10 focus hours a week, while elsewhere the most productive teams get 20 or more.

Meeting Culture

It’s easy for leaders to become convinced that they need to have a slew of meetings each week–one-on-ones, daily standups, planning sessions, scrums to coordinate across teams–but the cumulative impact can turn a calendar into something resembling Swiss cheese. Traditional meetings are obviously important–we need to talk to one another and work things out–but there’s also a big opportunity for businesses to try a new approach.

It can be as simple as eliminating those annoying, unproductive 15- to 60-minute gaps in your schedule by holding meetings back-to-back. Other experiments in meeting culture could include instituting no-meeting days. Or deleting every other occurrence of a regularly scheduled meeting. Or try asynchronous working practices through apps like Loom or Slack Audio that allow participants to respond to presentations or messages on their own schedules, rather than as a group in real-time.

In 2020, for instance, the company Loom—using its own remedy internally—switched its regular all-hands meeting to an asynchronous format on the theory that real-time meetings should be reserved for conversation rather than simple information sharing from a small group of people. Staffers watch short, prerecorded videos of updates from presenters when it’s convenient for them, and then participate in a company-wide Q&A in real-time. This approach allows the company to take advantage of everyone being together to engage in discussions and exchange ideas, Graham Gawthorne, then a member of Loom’s business operations team, wrote in a company blog post.

It’s a practice that starts at the top. When scheduling, leaders need to take a good, hard look at their team’s calendars and, rather than just grabbing any empty space that shows up, consider how to leave individual contributors the blocks of time they need to actually do their work. Keep in mind that studies have shown that it takes roughly 25 minutes to refocus and get back on track after an interruption, and that task switching can take up 40% of a team’s productive time.

And leaders need to preserve enough focus time for themselves, too—rather than trying to be perpetually available to their team members. If they’re not creating space in their own calendars to solve the larger problems, they’re probably not doing what managers should: Helping their teams to thrive.

I don’t know a single engineering leader whose boss isn’t asking, “How do we go faster? How do we do more with what we have?” with even greater urgency in these economically challenging times. The Clockwise analysis suggested that the answer, for many of us, is to stop ping-ponging from one meeting to the next and give your teams what they need most: Time to focus on their work.

November 3, 2022
Update to Open Source ZAP Tool Improves DAST Performance

An update to the OWASP Zed Attack Proxy (ZAP) open source dynamic application security testing (DAST) tool made available today improves performance by employing a multi-threaded passive scanner engine.

Version 2.12.0 of ZAP also adds support for HTTP/2 and should make it simpler to update the vulnerability scanning tool by making the spider that discovers new resources an add-on that is now capable of discovering more URLs.

ZAP is an open source penetration testing tool maintained by the Open Web Application Security Project (OWASP) designed specifically for testing web applications.

Simon Bennetts, founder and chief maintainer of ZAP, said the latest update will make it simpler for developers to discover vulnerabilities in their code faster. One of the reasons developers often don’t frequently scan their code for vulnerabilities is because the scans are perceived to be slow, he said. Of course, the longer a developer waits before scanning their code the longer it will take to complete the scan.

DAST tools are a critical element of any DevSecOps workflow because they enable developers to view weaknesses in application security as an attacker would—by analyzing a web application through its front end. That approach doesn’t eliminate the need for static application security testing (SAST) tools to discover vulnerabilities in source code; rather, a DAST tool helps developers better understand how cyberattacks target specific types of vulnerabilities in their applications, noted Bennetts. As an open source tool, ZAP is intended to remove the barriers to adoption of DAST tools by making it simpler for developers to download and install themselves, he added.

Interest in DAST tools is, of course, rising in the wake of a series of high-profile attacks against software supply chains. The debate that has ensued is how far to shift application security responsibility left toward application developers. More organizations are starting to require developers to embed security tools within their application development tools. Others are also embedding various types of security tools within their DevOps workflows to ensure scans are run should developers fail to do so.

No developer sets out to build an insecure application, of course. The primary issue is that many of the DAST tools being provided are not designed to be employed by developers, said Bennetts. Instead, they are designed for cybersecurity teams that then share results with developers after an application has been constructed, he added. That approach creates a dysfunctional relationship between application development and cybersecurity teams because developers are being asked to remediate vulnerabilities long after code was initially written, said Bennetts. In most cases, those developers have moved on to other projects so any context for how code was constructed is often lost, he noted.

Implementing DevSecOps best practices is, naturally, as much about culture as it is the tools being provided. However, the one thing that is clear is that tools adopted willingly by developers are going to be much more widely used than tools chosen by others on their behalf. In many cases, the shortest path to improving the overall state of application security is going to be an open source tool that developers can readily access themselves.

November 1, 2022
PlanSecOps: Incorporating Security Strategies in Design

Organizations that don’t adapt and change aren’t likely to survive. The same can be said about DevSecOps, a discipline created to ensure security is baked into the software development process, not an add-on after the code is approved. And as much as DevSecOps has changed the software development world for the better, it is time to evolve DevSecOps so that security is considered even earlier in the application development process—before a single line of code is even written.

We are already seeing glimpses of this early marriage of security and software development. Security is starting to be implemented from the initial design through integration, testing, deployment and software delivery. I’ve taken to calling the process PlanSecOps.

What is PlanSecOps?

With DevSecOps, developers integrate security measures into the code, then test to ensure it works. PlanSecOps starts the process earlier in the development cycle, incorporating security at the planning stage before any code is written. It’s easier to incorporate security fixes during the development cycle (i.e., before the coding phase) by including security pros who know from experience what kind of vulnerabilities exist in different types of software during the planning and architecture cycles.

Consider the process of building a house. Adding a hard-wired security system after the house is built usually requires some retrofitting with the aid of an electrician and contractor to install the system in a manner that doesn’t interfere with other parts of the electrical infrastructure. However, if a security system is part of the house’s blueprint, it’s ready to go when the build is complete with no risk of incompatibilities. PlanSecOps does the same thing for the development process.

PlanSecOps is a More Holistic Approach to Security

Companies want to grow, innovate and move quickly to deliver new functionality to improve the customer experience. It’s how they remain competitive. Shortening development cycles with Agile methods and DevOps teams helps them move faster.

Yet, attack strategies are only getting more sophisticated, and hackers are ready to jump on any vulnerability in an app. Like the game whack-a-mole, DevSecOps looks at individual pieces of code and applies patches. As soon as one vulnerability is patched, a never-ending set of new exposure points pop up. Fixing one problem may undo the patch for another, making each new issue more complex to address.

PlanSecOps is a more holistic approach to security by design. It’s putting a system in place versus just fixing issues as they emerge—patching different subroutines and making sure they all work together. PlanSecOps simplifies coding and testing to ensure functionality. It also simplifies the process downstream for the engineer, providing a faster, easier and more sustainable development process. It can cut weeks out of the development cycle.

Recommendations for Implementing PlanSecOps

Security patching is increasingly impractical in the development phase because of its complexity and the impact of privacy regulations like GDPR. Having one overarching strategy for data privacy is a better approach than trying to retrofit it into software after the coding phase. While this oversight is possible to handle in-house, it requires either one privacy engineer with a legal background and experience in software development or a team that covers all of this expertise. Both options are costly. Additionally, tech talent is challenging to recruit right now.

While at the RSA conference earlier this year, I saw several new companies that are creating security platforms designed to make security-by-design easier. These tools grade your code and provide a framework for the development process. Gathering this data could be a good start to identifying any issues, but you still need an expert who is smart enough to enact fixes based on the information the tool provides. Additionally, it’s difficult to vet which tools are right for your dev process. For example, a tool designed for the health care industry wouldn’t be applicable to a manufacturing application.

Alternatively, you could partner with organizations that have a security-by-design approach and are already handling security planning during the architecture phase. Partnering with software development companies like this is typically less expensive than hiring someone in-house. Plus, you’ll get the experience you need to bake security into your applications from the beginning.

Security Needs to Start Early and Never End

October was cybersecurity awareness month and reminds us that cybersecurity is everyone’s responsibility. To stay competitive, companies need to embrace that responsibility and address the ever-evolving security risks at the beginning of DevOps cycles. The software development journey has no end because new features will always be needed and new technologies will emerge. The key to success is to ensure that everyone in the software development process shares accountability for security and that all systems are as automated as possible. With improved collaboration and understanding of risks, organizations can better respond to both cybersecurity risks and software development innovations as they look to the future.

November 1, 2022
Building New Value in IT Systems Management

For decades, companies treated the IT system as a cost center not much different from facilities maintenance. The job of IT was to keep the lights on, ensuring that the technology a company used worked and that the costs of keeping it working were kept under control. Those days are well over. Not only is technology an operational necessity, but everyone now recognizes that the way companies strategically use technology—whether they buy it, rent it or build it—has a direct impact on company performance. This goes beyond efficiency. Technology is key for everything from customer acquisition and engagement to competitive differentiation and advantage.

As it turns out, however, not every company has been able to rethink and reconfigure its IT system to meet these new demands. That’s not surprising. Not only does this require a mindset shift from the C-suite on down, but it also requires restructuring the IT function to ensure it supports business objectives in a consistent and measurable way.

While transforming IT from a cost center to a profit center can hardly happen overnight, there are three things that any company can do to turn IT into both a business enabler and a business driver.

1. Establish Full Transparency Over Your IT System

A mission-critical IT system needs to have a thorough understanding of what the organization’s IT landscape looks like. Spending money on duplicate applications and unused licenses is a waste. Unknown SaaS applications pose a persistent security risk. Optimizing spend and improving security are table stakes for business-enabling IT.

The fact that anyone in a company with a credit card can subscribe to a SaaS service is the main challenge. Effectively tracking down all SaaS applications and licenses, along with monitoring SaaS usage, can’t be handled manually. What is needed, as with other tedious tasks, is automation. For example, by integrating a SaaS management platform (SMP) with SSO and expense management solutions, organizations can automate the discovery of SaaS. When the SMP also integrates with the primary SaaS vendors companies rely on (Microsoft, Google, Salesforce, etc.), it allows organizations to keep track of usage.

The goal here isn’t for a centralized IT function to exercise more control over the software used by organizations. Instead, the goal is leveraging automation strategically to produce the kind of data-driven insights that allow organizations to make better, more informed decisions about the technology it uses.

2. Promote Engineering Efficiency

All companies today are software companies. This means that the engineering function needs to be thought of us as part of the overall IT estate. Not only does the IT system need to support engineering as it would any other business function, but the technology created by engineering itself inevitably becomes part of the broader technology landscape managed by IT.

Mission-critical IT supports engineering efficiency in at least two ways. First, IT should provide the tools and capabilities needed to drive engineering efficiency. For a long time, measuring the efficiency of engineering was either not done at all or was based on meaningless vanity metrics such as lines of code. Recently, DORA metrics have emerged as the scientifically validated method, widely trusted by engineering teams themselves, for tracking efficiency. IT needs to enable easy tracking of these metrics.

IT should also facilitate the creation and maintenance of a service catalog for engineering teams. Maintenance of this catalog not only promotes the reuse of services, itself a hallmark of engineering efficiency but also makes it possible to quickly mitigate security issues associated with microservices (Log4j being just one example from the last 12 months).

Beyond efficiency, however, IT can also support in-house software creation by helping engineering teams with value stream management so they can track the business impact of the software they create. While efficiency can have a business impact (realized through time/cost savings), software drives the business forward when it effectively meets customer needs. IT can facilitate these insights by connecting the dots between customer feature requests, product changes and increased adoption (of products and features).

3. Make Enterprise Architecture Strategic

An IT function serving as a mission-critical part of the organization cultivates a comprehensive overview of the software landscape and supports engineering efficiency, as suggested, by viewing the development environment as an integral part of the broader technology estate. However, IT system leaders need to do something more to effectively collaborate with the business leaders and drive the business forward.

Specifically, IT leaders need to provide the business with insight into all the ways technology influences business performance. This means highlighting risks that need to be addressed, uncovering opportunities that should be pursued, and suggesting options for future planning. Thoughtful and strategic enterprise architecture management here is the key.

A strategic approach to enterprise architecture management means focusing less on governance (who gets to use what) and more on reducing complexity to promote agility and quick decision-making. The first step in this direction is the adoption of a common language that aligns the business and IT. Business capabilities and the creation of business capabilities maps for different departments serve this purpose.

To make decisions about technology, business leaders need to know what they are working with. Reliable and current data is essential. For this reason, your enterprise architecture management needs to prioritize ongoing data collection and the maintenance of data quality.

Finally, to make objectives and options transparent, IT needs to be capable of strategically displaying all enterprise architecture data in a way that can be easily understood and acted on.

Where Do You Start?

Taming an unruly SaaS landscape, making it possible to build better software and guiding technology strategy are all easier said than done.

The good news is, ongoing innovation has created solutions that are easier to use, effectively leverage automation and integrate with all relevant systems. In other words, the tools are there. All that’s needed is the commitment to transforming the IT system and developing it into the critical business function it can and should be.

October 28, 2022
Fermyon Adds Managed PaaS for Building Wasm Applications

Fermyon Technologies this week launched a hosted platform-as-a-service (PaaS) environment, dubbed Fermyon Cloud, that promises to make it simpler to build WebAssembly (Wasm) applications.

Announced during the Cloud Native Wasm Day event during the KubeCon + CloudNativeCon North America conference, Fermyon Cloud is now available in open beta.

Fresh from raising $20 million in funding, Fermyon CEO Matt Butcher said IT teams can quickly build and deploy Wasm applications using a Fermyon Spin development tool and a Fermyon Platform the company launched earlier this year.

Fermyon Cloud adds an opinionated PaaS environment managed by Fermyon that can start up Spin applications in less than a millisecond. It uses a serverless application programming interface (API) that makes it possible to cache and optimize applications as they are loaded, noted Butcher.

Originally developed more than five years ago by the World Wide Web Consortium (W3C) to create a common format for browsers executing JavaScript code, Wasm is now used to rapidly build lighter-weight applications that can be deployed on any server platform. In effect, the promise of being able to write an application once and deploy it anywhere is finally being realized some 25 years after the initial introduction of the Java programming language.

Wasm isn’t necessarily going to replace existing approaches for building applications, at least not any time soon, but it does provide an alternative to serverless computing frameworks for developing lighter-weight applications that run faster.

In addition, at a time when organizations are becoming more concerned about application security, the appeal of Wasm is clear. Existing approaches to building applications rely on the aggregation of software components that tend to lack distinct boundaries between them. As a result, it becomes relatively simple for malware to infect all the components of an application. In contrast, Wasm code runs in a sandboxed environment that isolates execution environments to eliminate the ability of malware to laterally move across an application environment.

Wasm is especially well-suited for building lightweight applications that previously might have been deployed on a serverless computing framework, noted Butcher. The issue developers are encountering when using a serverless computing framework is that those frameworks are based on containers that have comparatively slow startup times, he added.

It remains to be seen how much traction Wasm gains in the months ahead, but Butcher said he expects most backend services, such as databases, will continue to be built using containers. Fermyon is betting, however, that many future cloud-native applications built by the average developer will be constructed using Wasm. In the longer term, Wasm will also soon be used to build applications infused with machine learning algorithms, said Butcher.

In the meantime, DevOps teams should get ready for more Wasm code to move through continuous integration/continuous delivery (CI/CD) pipelines. The challenge, of course, is that code will need to be managed alongside all the other software artifacts moving through those pipelines, as well.

October 27, 2022
Sigstore Code Signing Service Becomes Generally Available

A free digital signing service for software created by the Sigstore open source community has become generally available this week via the cloud.

Announced at the SigstoreCon event that occurred during the KubeCon + CloudNativeCon North America conference, the cloud service makes it possible for developers to both cryptographically sign artifacts and verify that the components used to build applications are secure.

The Sigstore community operates under the auspices of the Open Source Security Foundation (OpenSSF), an arm of the Linux Foundation. Sigstore project sponsors, including Google, Red Hat, GitHub and Chainguard, have committed to operating a service with a 99.5% uptime and round-the-clock pager support. More than 70 organizations, including Shopify, Autodesk, Trail of Bits and Rancher Government Solutions are actively involved in maintaining and scaling Sigstore.

More the four million Sigstore signatures have been logged using Sigstore thanks mainly to Sigstore support that is already included by maintainers of open source Kubernetes and Python projects. The npm community also announced it is working to integrate Sigstore in all packages used to build JavaScript applications.

Bob Callaway, co-founder of Sigstore and technical lead and manager for the Open Source Security Team at Google, said this service will make it much simpler for developers to add digital signatures to code in a way that can be more easily verified within a software bill of materials (SBOM).

The goal now is to expand the number of open source projects that will commit to employing Sigstore to better secure software supply chains, he added.

The security of open source software became a major concern in the wake of the open source Log4j zero-day vulnerability. Sigstore was under development prior to that disclosure, but the Biden administration’s executive order requiring Federal agencies to verify the security of open source software has enabled the availability of more resources for the project.

In response to the executive order, the OpenSSF outlined a 10-point plan to secure open source software that would require more than $150 million in funding. One of those goals is to have 50 of the top 200 projects and 1,000 of the top 10,000 projects adopt an interoperable approach to software signing. That project was estimated to cost $13 million for the first year and $4 million per year beyond, with a one-time additional $10 million required after the first year.

It’s not clear how broadly developers will employ digital signatures, but given the current level of concern, it’s probable most organizations will soon require any code they use to be digitally signed so it can be verified as immutable. The next big challenge, of course, is finding a way to operationalize the collection of all the SBOMs that will include those signatures. After all, SBOMs are only the first step in a larger DevSecOps workflow that will enable organizations to accept or reject software components based on all the data being collected.

October 27, 2022