devopsy.kinsta.cloud

Category: IT as Code

Best of 2022: SRE Vs. Platform Engineering: What’s the Difference?
As we close out 2022, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2022.

Site reliability engineering (SRE) teams and platform engineering teams share similar goals—like maximizing automation and reducing toil—and similar methodologies. But they have different priorities, and use somewhat different tools to achieve them.

What are SREs? What are platform engineers? How is each role similar and different? This article will answer all your questions.

Responsibilities of SREs and Platform Engineers

The main responsibility of site reliability engineers is ensuring that IT systems are reliable, which means that the systems meet performance requirements. Part of their job includes working with developers and IT operations teams to maximize the reliability of applications as they move down the software delivery pipeline.

Meanwhile, platform engineers focus on managing and optimizing the software delivery process. You could think of this role as one that translates DevOps principles into practice by finding ways to implement continuous delivery, continuous improvement and other DevOps priorities.

Thus, both SREs and platform engineers play a role in managing the software delivery process and finding ways to make it as smooth and efficient as possible. They also share a common enemy—toil—in the sense that both groups seek to avoid manual, inefficient processes by automating as much as possible. SREs automate complex incident response operations using tools, for example, while platform engineers might deploy methods like GitOps to automate some aspects of software delivery.

Differences Between SRE and Platform Engineering

That said, SRE and platform engineering are distinct roles. The key differences boil down to:
- Goals: The main job of SREs is maximizing reliability, which is different from optimizing the speed and efficiency of software delivery operations. Theoretically, you could have a highly reliable system even if your software delivery chain is manual and slow.
- Scope of role: Software delivery operations are the main focus of platform engineers. SREs care about software delivery, too, because the way applications are created plays a role in reliability and fixing issues. But SREs also have many other responsibilities, like incident response and helping to manage infrastructure, which fall beyond the scope of software delivery.
- Tools: SREs rely on tools that help them discover and solve various types of reliability issues. In contrast, platform engineers leverage tools like source code managers and continuous integration (CI) servers to help automate software delivery.
So, although SREs and platform engineers may use similar methodologies and possess similar skills, their day-to-day operations tend to look quite different.

Should You Pursue an SRE or Platform Engineer Career?

Given the skills overlap between SRE and platform engineering, some engineers are a good fit for either role. But which one is better, from a career perspective?

Salary-wise, there’s not a whole lot of difference. Glassdoor pegs the average salary of platform engineers at about $115,000 compared to $127,000 for SREs. SREs may earn a little more (and it’s worth noting that SRE salaries can vary widely), but the difference in pay is not as great as that between, say, IT operations engineers (who make a mere $77,000, according to Glassdoor) and SREs.

The roles are also similar in terms of demand. Unlike software engineering or even DevOps engineering, SRE and platform engineering are both roles that have begun to become popular only in recent years. SRE as a concept has been around for a while—it originated at Google in the early 2000s—but it wasn’t until recently that most companies began seeking SREs for their teams. Likewise, platform engineering didn’t become a thing until the advent of microservices and cloud-native everything pushed companies to devote more engineering resources to manage their increasingly complex software delivery processes.

What this means is that, at least for now, it’s easy to find jobs in SRE and platform engineering as long as you have the right skills. Many companies are eager to hire for both types of roles.

Choosing the role that is right for you, then, depends mostly on your preferences and how you like to work. The life of a platform engineer is likely to be somewhat more predictable than that of an SRE because platform engineers don’t have to take the lead in managing incidents when something breaks at 2:00 a.m. On the other hand, SREs enjoy a more diverse set of responsibilities, which can make the job more exciting—especially if software delivery tools like Git or Jenkins don’t make you excited to get out of bed in the morning.

Conclusion

Platform engineers and SREs play central roles in automating complex processes and eliminating toil. But they tackle these issues from different angles and they use different tools. The right role for you depends on what you enjoy doing most.
December 22, 2022
Opvizor Extends Monitoring Reach to the Cloud

Opvizor, a unit of Codenotary, has extended its monitoring capabilities to cloud computing environments starting with support for Amazon Web Services (AWS) and Microsoft Azure.

Codenotary CTO Dennis Zimmer said Opvizor aggregates data to provide a more efficient approach to applying analytics to surface performance and risk issues.

Previously, Opvizor was optimized for instances of VMware vSphere running in an on-premises IT environment. Now the unit of Codenotary, a provider of a service for generating software bills of materials (SBOMs), is extending those monitoring capabilities to the cloud.

That transition comes as many organizations are looking to strike a balance between monitoring pre-defined metrics and observability platforms that make it possible to surface unknown potential issues that could adversely affect IT environments.
It’s still early days as far as observability is concerned, so Opvizor is focused on meeting most IT teams where they are today as they further embrace cloud computing, said Zimmer.

Observability, in general, promises to query not just logs and metrics but also distributed traces that are applied to specific processes. In that way, observability allows organizations to detect patterns that have not been predefined. In effect, an observability platform makes it simpler to debug application environments where the number of dependencies that exist between services are becoming too complex to track manually, much less decipher. Without the aid of an observability platform it can take weeks to discover the exact cause of an application’s performance degradation.

Of course, those applications will need to be instrumented using agent software capable of generating the data observability platforms require. Fortunately, open source projects such as OpenTelemetry are helping to drive down the total cost of instrumentation.

However, in the absence of observability, most IT teams will rely on existing monitoring tools. Opvizor is making a case for centralizing monitoring across multiple platforms to reduce costs, noted Zimmer.

Heading into 2023, each IT team will need to decide how and when to rely on traditional monitoring tools versus observability platforms. Many observability platform providers are justifying the acquisition of a new platform based on cost and the ability to eliminate the need for multiple monitoring tools. However, it remains to be seen whether IT organizations will prefer to employ both monitoring tools to track predefined metrics alongside observability platforms.

Regardless of approach, the reality is that IT environments are becoming more complex to manage. In addition to running workloads in multiple cloud platforms and on-premises IT environments, organizations are deploying emerging cloud-native applications based on containers alongside existing monolithic applications deployed on legacy virtual machines. As workloads are deployed on multiple platforms, the total cost of IT starts to rise. One way to contain those costs is to standardize on a set of tools that can be applied to multiple platforms.

The pressure to rationalize toolsets only increases during any period of economic uncertainty. The challenge, of course, is convincing one team to give up their preferred tool in favor of another to reduce costs.

December 20, 2022
How SASE Can Ease DevSecOps Adoption
DevSecOps is a software development methodology that merges development (Dev), security (Sec) and operations (Ops) into one team that integrates security throughout the entire software development life cycle (SDLC). The goal is to deliver high-quality applications quickly and securely.

The traditional software development life cycle introduces security in the late phases of the SDLC. However, this approach cannot protect against sophisticated cybersecurity attacks. Today’s cybersecurity landscape requires shorter, frequent iterations to quickly patch and fix security issues. DevSecOps integrates security into the continuous integration and continuous delivery (CI/CD) pipeline to ensure teams can address pressing security issues at DevOps speed.

Many organizations are enthusiastically adopting DevSecOps but, in the process, discover they don’t have the necessary infrastructure. DevSecOps requires smooth global collaboration between teams and requires that security controls are built into the IT environment. This is where SASE comes in.

What is Secure Access Service Edge (SASE)?

Secure access service edge (SASE) is a network security model that provides network connectivity with security based on identity, real-time security context and corporate security policies. It is aligned with the zero-trust security paradigm, ensuring that connections are denied by default unless a verified identity has permission to access a specific application, service or edge location.

SASE unifies networking and security functions into one fully integrated service delivered in the cloud. SASE includes several technologies: software-defined wide area networking (SD-WAN), secure web gateway (SWG), cloud access security broker (CASB), next-generation firewall (NGFW) and zero-trust network access (ZTNA).

A key benefit of SASE is enhanced network security. SASE services enhance network security with a granular approach to network protection, detecting and blocking network attacks such as distributed denial of service (DDoS) attacks, man-in-the-middle (MitM) attacks, phishing, email spoofing and malware with deep security scans.

Additional benefits of SASE include:
- Lower cost compared to traditional networks because SASE includes fewer on-premises hardware components and features previously purchased from multiple vendors.
- Easier maintenance because it provides one pane of glass that allows IT teams to manage all applications and users wherever they are.
Components of SASE

Cloud-access Security Broker (CASB)

CASB acts as a bridge between users/devices and cloud applications. It allows organizations to apply security policies, two-factor authentication and single sign-on to all cloud applications, preventing unauthorized devices and individuals from accessing sensitive assets and denying access by default.

Zero-Trust Network Access (ZTNA)

ZTNA ensures that users or devices have explicit permission to access applications or resources. It is a critical component of a zero-trust security architecture, ensuring that internal, private applications are hidden from users who should not have access to them. It also enables secure remote access through layered authentication. ZTNA provides flexible security to meet modern security requirements.

Software-Defined Wide-Area Networking (SD-WAN)

SD-WAN is a connectivity architecture that separates network hardware from the physical control layer. It improves network performance by enhancing and simplifying WAN performance and management. SD-WAN supports modern, cloud-based applications and services while reducing connectivity costs. Combining SD-WAN with advanced security features provides a foundation for enterprises to transition to SASE.

Secure Web Gateways (SWG)

SWG protects online devices from malware infection, enforces corporate security policies and filters unwanted websites in user-initiated internet traffic. SWG provides URL filtering, application control, DLP, antivirus, sandboxing and SSL inspection. All these capabilities protect users from harmful websites and enforce security policies while ensuring full web access and promoting productivity.

Firewall-as-a-Service (FWaaS)

FWaaS is a firewall solution delivered as a cloud-based service. It provides hyperscale next-generation firewall (NGFW) features, including web filtering, advanced threat protection (ATP), intrusion prevention systems (IPS) and domain name system (DNS) security. By integrating FWaaS into the SASE platform, organizations can provide a wide range of cybersecurity capabilities at the edge.

Centralized and Unified Management

The modern SASE platform enables IT administrators to manage SD-WAN, SWG, CASB, FWaaS and ZTNA with centralized, unified management across networks and environments. This allows IT team members to focus on more pressing areas and improves the user experience for the organization’s mixed workforce.

How SASE Will Impact DevSecOps and Security in Organizations

SASE can help secure internal interactions and applications. As a result, the burden on DevSecOps teams is reduced. DevOps teams can use zero-trust network access (ZTNA) to further secure the applications running on SD-WAN. These technologies keep all interactions between endpoints and applications secure.

The SASE model can also help protect mission-critical applications and sensitive data that cannot run on the public internet. To protect these assets, SASE obfuscates traffic, restricts access with a zero-trust architecture, and secures all network entry points with NGFW. It continuously evaluates application traffic for security threats.

Facilitating Collaboration

DevOps teams are focused on time-to-market and are constantly working to accelerate the CI/CD pipeline. They need to collaborate remotely over a reliable and secure connection. DevOps teams are also working to reduce their reliance on network and security teams. The SASE model helps address these problems.

SASE helps reduce collaboration issues by unifying WAN and network security. SASE solutions provide optimized performance and strong security, so DevOps teams don’t depend on infrastructure staff to provision resources. It gives teams full control over operations without compromising performance or security.

Providing Built-In Security

SASE offers the basic network security features required to secure a DevOps project. This allows teams to integrate different security mechanisms into their networking stack, with all security services sharing an integration context. This plugs the gaps in traditional security architecture often exploited by attackers and protects applications from threats.

Improving Incident Response

SASE can immediately block various attack vectors with security controls embedded in the network fabric, supporting the incident response team’s efforts. SASE increases visibility into behavioral anomalies and security incidents in a hybrid environment.

Integrating SASE solutions into a security information and event management (SIEM) system allows incident responders to gain greater visibility into traffic anomalies and the automated security actions taken by the SASE tools. SASE features like NGFW, SWG, IPS and anti-malware might already contain or eliminate many incidents.

Providing More Reliable Infrastructure

DevOps teams need fast, reliable application performance. SASE offers integrated load balancing and failover capabilities that can significantly improve the network’s overall performance.

The SASE architecture can connect all the edge devices, remote users, data centers and cloud resources to a secure, self-healing, fully optimized global network. If a circuit fails or the path becomes congested, the fabric can automatically switch to an alternate path.

Conclusion

In this article, I introduced DevSecOps and showed how SASE, a modern platform that provides fast network connectivity and security at the edge, can support its adoption. DevOps teams can use SASE security components to secure applications across on-premises data centers and clouds. SASE can encrypt and inspect traffic to protect it from threats, ensuring that workloads, users, and development systems are secure by default.

With SASE, DevSecOps teams have the infrastructure they need to secure the environment and can focus on integrating security tests and remediations into the development life cycle.
December 19, 2022
How Enterprise Software Architects can Design for Sustainability

Organizations of all sizes are feeling the pressure to introduce more aggressive sustainability measures to combat climate change. For example, most cloud service providers have announced significant climate pledges to either reduce or offset their carbon emissions. But these initiatives can only go far to move the needle—it’s up to individual companies and departments to participate in curbing their climate impact, and DevOps certainly has a role to play in enacting positive change.

One way to design for sustainability is to optimize information technology systems to reduce waste. Enterprise IT typically supports a lot of unnecessary technical debt and perpetuates toilsome tasks that contribute to energy inefficiencies. Removing unused instances and features or idle workloads that aren’t contributing value could be an easy way to reduce waste. Yet other optimizations will require more effort.

I recently chatted with André Christ, co-founder and CEO of LeanIX, to discover what techniques enterprise-level software architects can use to get the most out of their technology modernization efforts while leaving the least carbon footprint. According to Christ, optimizing existing processes, using cloud-native technologies and leveraging value stream management are some tactics architects can take to “do more with less.”

1. Match Technology to Sustainability Targets

First, technology leaders must understand the capabilities of their business that could help contribute to meeting sustainability targets. “This requires understanding and systematic mapping,” said Christ. “It’s really about understanding what you can do as a company to contribute to sustainability in a more holistic way.”

For example, a routing and logistics provider might optimize operations by redesigning its floor plan to maximize efficiency and reduce energy use. Similarly, Christ recommended software professionals take stock of their existing capabilities to determine what should change. This could equate to discovering internal microservices that aid one department and extending them across the entire organization.

Optimizing data transfers is another way to create a leaner IT system. For example, teams could reduce constant polling by eliminating overfetching and underfetching or embracing a new API standard, like GraphQL, said Christ. Cutting out these superfluous calls reduces unneeded energy consumption.

2. Ensure Cloud-Architected, Not Lift-and-Shifted

Cloud migrations can reap significant benefits in terms of scalability and flexibility. But not every cloud migration delivers tangible sustainability benefits. AWS identified six unique strategies for migrating applications into the cloud: Rehosting (known as lift-and-shift), replatforming, repurchasing, refactoring, retiring and retaining. While early gains may be met simply by rehosting applications, replatforming or refactoring them completely with cloud-native components will likely deliver the best optimizations.

“If you only lift-and-shift applications into the cloud, they will keep running just as inefficiently as a virtual machine,” said Christ. Therefore, architects should design for cloud-native whenever possible rather than simply porting legacy applications to the cloud. On the other hand, it may be prudent to replace specific legacy components with SaaS or retire them altogether. As such, it’s crucial to analyze your existing landscape before making a cloud migration to ensure changes are both cost-effective and advancing sustainability goals.

3. Practice Value Stream Management

Practicing value stream management is another potential strategy to cut bloat by ensuring product teams always create more value for the end customer. Planview defined value stream management as such:

“Value Stream Management is a management technique or practice that focuses on increasing the flow of business value from customer request to customer delivery.”

This frame of mind could help engineers make more streamlined decisions about what they’re creating. But to achieve value stream management, organizations will require enhanced visibility into how individual services perform, their dependencies under the hood and their approximate emissions.

The core question you should be asking product teams, said Christ, is how carbon-efficiently are you operating in relation to the number of users you are serving? The answers will highlight which aspects of the business require the most optimization.

4. Tie Sustainability to the Business Bottom Line

Many sustainability pledges are founded on carbon offsetting, in which the company purchases “offsets” of its emissions, usually by planting trees or preserving forests. But, the practice of carbon offsetting has received criticism as being ineffective at stemming rising global temperature levels. So what does an honest climate pledge look like that’s more than greenwash? Well, perhaps one more closely associated with the bottom line.

Taking the idea of value stream management one step further, Christ argued that a real climate pledge would involve reducing carbon footprint by a certain percentage for each new dollar generated. As a business scales and its revenue increases, it should constantly reduce emissions in parallel with this growth. This would equate to assigning a dollar value for every CO2 ton and putting it into the balance sheet, said Christ.

Doing More With Less

Nations are striving to reduce carbon emissions through sweeping legislation. Yet, national goals will be insufficient to meet the target decline of 43% percent by 2030 and net zero by 2050, the United Nations reported. Thus, it will take effort from the private sector, as well.

We’ve identified some steps above to do more with less, yet many current, unsustainable practices are culturally ingrained, making them challenging to change. It will be the work of enterprise software architects to break it down and apply smarter designs to cloud-native applications. This will likely require centralizing views of internal services to enhance visibility and reporting. “You need good visibility into what you’re building and what it’s composed of to reduce the footprint,” said Christ.

December 19, 2022
Salesforce Launches Low-Code DevOps Platform

Salesforce made generally available today a low-code DevOps Center service on its infrastructure through which developers are provided an opinionated platform for building custom applications. The Salesforce DevOps Center service is based on the same object model Salesforce uses to construct its own applications.

Karen Fidelak, senior director of product management at Salesforce, said after nearly two years of development effort, this platform will make it simpler for both professional and citizen developers to build applications consistently using a common Source Control repository. That’s especially critical for professional developers that may need to access source code previously created by a citizen developer, Fidelak noted.

In 2023, Salesforce will embed more robust continuous integration/continuous delivery (CI/CD) capabilities within the platform to make it simpler to deploy custom applications on the Salesforce platform, Fidelak added.

In general, the number of developers willing to embrace DevOps best practices to build Salesforce applications has been surprising, since the platform was initially launched in 2020, noted Fidelak. She noted that both citizen and professional developers are looking to adopt best practices that provide a set of guardrails that ensure high-quality applications are secure. Salesforce anticipated a much higher level of DevOps resistance, added Fidelak.

The DevOps Center platform enables development teams to track and deploy changes to custom objects on the Salesforce platform as Work Items that can be integrated with other Salesforce Flows, a set of process management tools the company provides. As development teams make changes in their sandboxes, DevOps Center automatically tracks them. Developers can then point and click to promote their desired metadata components via custom pipelines they define.

In addition, Salesforce also provides optional integrations with version control systems such as GitHub to centralize the management and governance of artifacts.

Finally, Salesforce is committing to tightening integration between DevOps Center and multiple software-as-as-service applications such as Tableau and middleware platforms such as Mulesoft, said Fidelak.

It’s not clear how much low-code is moving through DevOps pipelines these days, but the volume is increasing as more developers rely on these tools to accelerate application development. The issue that creates is citizen developers typically don’t have the expertise required to build and deploy secure applications at scale—at least not applications that anybody other than themselves really wants to use. Ideally, citizen developers should be supported by application development platforms and DevOps teams that ensure security guardrails are in place for building applications at scale. DevOps teams should also reduce the friction that a citizen developer will most certainly encounter when building any application.

The fact is, in the absence of that support, most citizen developers—who typically have other tasks that require their attention—will simply abandon an application development project should projects become overly complicated. None of this means organizations shouldn’t be working toward building their own army of citizen developers. The increased reliance on citizen developers is part of an inexorable wave of the democratization of IT. The challenge is making sure those applications are of the highest quality possible regardless of who actually developed them.

December 15, 2022
EU Data Privacy: Try Again | SkyPilot: Choose Cheapest Cloud | WFH: Better Meetings

Welcome to The Long View—where we peruse the news of the week and strip it to the essentials. Let’s work out what really matters.

This week: EU-U.S. Data Privacy Framework reemerges, Berkeley brings cloud selection box, and proof that remote work is good work. (more…)

December 15, 2022
Why Backups and Compliance Go Hand-in-Hand

It’s hard to run a business. Besides the numerous challenges you have to deal with daily, ensuring the security of your business and customer information is essential for operating smoothly. In order to mitigate information security risks that would affect companies and their users, a number of security regulations have been created, including a set of best practices that companies must follow.

Compliance with these regulations will allow you to:

● Reduce security and privacy risks
● Strengthen control of key processes
● Align cybersecurity requirements with business processes
● Better understand cybersecurity goals and how to handle business security challenges
● Maintain effective cybersecurity programs
● Build customer trust and improve company reputation

One critical requirement to achieve compliance is backups. Organizations back up information that’s vulnerable to threats like software or hardware failures, cyberattacks or human error. Any one of these problems could potentially lead to data loss, system malfunctions, financial losses and reputational damages. In this post, you’ll learn more about why data backups are an important part of compliance and about the benefits of having a robust backup strategy.

Why are Backups Important for Compliance?

Regulations like GDPR, PCI-DSS and HIPAA, along with others, were created to ensure that organizations implement the most reliable methods to secure all types of sensitive data from infrastructure failures and malicious attacks.
Compliance can’t be achieved unless an organization handles data in a way that adheres to the outlined regulations.

Certifications like ISO 27001 and SOC 2 are considered the most thorough audits an organization can go through to prove they have taken all the necessary steps to protect business and user data. Unlike the regulations mentioned above, ISO 27001 and SOC 2 aren’t legal requirements, but they’re especially beneficial to SaaS companies, data centers and organizations that deal with sensitive information. They make it very clear that the company takes data security very seriously and considers it a top priority. By properly implementing the data and privacy controls required, you can increase reliability and user trust as well as gain a competitive advantage over other companies.

To be able to obtain such certifications and comply with regulations and different standards in general, you’ll have to maintain robust, up-to-date backup processes that ensure data is always protected but also available to users—even in cases of unexpected events like natural disasters, cyberattacks, data losses and human error. In other words, to comply with regulations, your backup processes must match your business continuity plan and the data backup tools you are using should be able to handle your backup processes.

Backups, of course, do more than enhance business continuity, as mentioned above. Although they can’t prevent an attack or a data loss from happening, they’re an integral part of your overall security strategy since they allow you to restore lost or corrupted information, mitigating the consequences of such an event.

There’s no fixed rule for how frequently you should back up. Still, ideally, to secure valuable information, you should implement a combination of full and partial backups as often as possible. Fortunately, great data backup solutions can efficiently handle this complex but crucial task.

The Difference Between Backups and Compliance

Backups and data availability are just one of the many requirements for a company to comply with any regulation. It’s an important part, but it’s not enough on its own. Obtaining a security certification isn’t a quick and easy process that you can decide to do and then finish a month later. It’s a time-consuming process that will require buy-in from every member of your team and will ultimately involve in-depth tests and evaluations of how you secure data.

Although each certification is slightly different, all of them require a company to implement a wide range of security procedures. For example:

● Structure your organization in a way that allows optimal management of your services.
● Have a strong disaster recovery plan.
● Communicate in detail with users about how your system works, your security policies and your processes.
● Perform risk assessments regularly to identify risks, measure their impact and create a plan to address them quickly and effectively.
● Continuously monitor your security controls to verify they’re operating as expected.
● Make adjustments as needed to stay ahead of the latest security threats.
● Control physical access to your devices and prevent unauthorized access to your systems.
● Integrate best practice security procedures into your day-to-day workflows.
● Optimize system operations to detect vulnerabilities early and deal with security incidents.
● Clearly describe how you handle changes in your infrastructure to ensure that they won’t affect your business operations.

The above is far from an exhaustive list, nor will it guarantee regulatory compliance. There are numerous criteria you need to fulfill. Although compliance might seem a huge undertaking, the benefits surpass the difficulties.

As the security risks in the technology world are constantly changing and becoming more sophisticated, organizations must be able to deal with them or face the consequences. For businesses that want to protect their customers and themselves, following security standards has become necessary. But security compliance isn’t an easy task, and it’s made more complicated by the fact that all of the vendors you use must also be compliant.

Having a reliable data backup strategy is a crucial step for compliance with regulations and achieving business continuity. Fortunately, there are top-notch data backup tools that can make this complex process easier. These tools allow you to back up regularly to secure your valuable data, and will often automatically run backups on a schedule of your choosing. If you wish to remain compliant and ensure your data is protected, I highly recommend installing a backup service.

December 15, 2022
Massive Number of Transitive Dependencies Traced to Open Source Code

An analysis of nearly 2,000 software packages published by Endor Labs found 95% of all application vulnerabilities can be traced back to a transitive dependency created when a developer used an open source component.

The study, conducted by the Station 9 research arm of Endor Labs, a provider of a platform for identifying software dependencies, concluded there’s still a 32% chance those software packages would have known vulnerabilities even after components are upgraded to the latest version.

Endor Labs CEO Varun Badhwar said vulnerabilities often remain because the last update made to one of those software components may have been made several years ago even though there are existing known vulnerabilities that affect it. Development teams can’t assume the latest version of a software component is secure, he added.

In general, functional dependencies are created whenever developers download a third-party component, he noted. The most important thing for any software development team to determine when assessing actual risk levels created by those dependences is determining how accessible any given vulnerability is to an attacker regardless of its severity score, noted Badhwar.

In the wake of a series of high-profile breaches, there has been an increased focus on software supply chains. The challenge is most developers don’t have a lot of cybersecurity expertise. They often create patches for applications based on a list of potential vulnerabilities surfaced by cybersecurity teams. The issue, of course, is that just because there is a vulnerability it does not immediately follow that the affected software component can be externally accessed.

Endor Labs is making a case for a graph-based platform that identifies dependencies between the software components that make up an application environment. That approach makes it simpler to prioritize remediation efforts based on the impact a vulnerability might actually have and narrows the current divide between cybersecurity teams and application developers. By the time cybersecurity teams alert developers to a vulnerability they often have moved on to other projects. As a result, developers often lack context because it may have been months since they last looked at the impacted code.

Of course, the inclusion of DevSecOps best practices should improve the overall state of application security as more responsibility for it shifts left toward developers. However, achieving that goal will require more than just giving developers access to software composition analysis (SCA) tools that only surface vulnerabilities in source code as it is being developed, noted Badhwar.

In the meantime, the efforts to remediate all existing application vulnerabilities will be measured in years, so organizations need to determine where to focus their efforts. After all, every minute spent developing and deploying patches is less time that can be allocated to building and deploying new code. The trouble is that as more new code is written, the number of vulnerabilities that could be exploited increases and makes a bad situation worse.

December 12, 2022
5 Tips to Consider When Introducing Infrastructure Automation

Although we discuss infrastructure automation often, the fact is that a lot of manual processes still exist throughout DevOps. Whether it’s rewriting scripts to spin up new servers, updating cloud-native policies or configuring computing environments, manual toil is an all-too-common reality. To make matters worse, engineers commonly create lengthy scripts that work in isolation but are too bulky to be reusable by other developers working with slightly different constraints.

More infrastructure automation is the key to increasing deployment agility, but setting aside time to automate your daily workflow can easily take a back burner, especially when developers are already behind on their long list of to-dos. So, for the time-pressed, where should they start? What exactly should be automated? And how can we effectively reuse and share automation to help other areas of the business?

I recently connected with John Laffey, technical product marketing director, Puppet. Laffey has thirty years’ worth of tech support and engineering operations knowledge under his belt and was “doing DevOps before it was called DevOps.” He shared with me five helpful tips to think about when introducing more infrastructure automation into your workflows. Below, we’ll expand on each of those points and consider other best practices around automation as the industry moves toward platform engineering.

1. Automate Things That Interrupt Your Day

First, Laffey recommended starting with the things that are easy to fix. These are the tedious actions that interrupt your day. Perhaps a disk runs out of space and troubleshooting takes 15 or 20 minutes. Minor interruptions like this might seem like part of the job, but they definitely add up over time.

2. Automate Things You Can Reuse

Secondly, try not to automate things for an ultra-specific purpose, said Laffey. Instead, focus on building automation that is more generic and can have more value to others. This follows the DevOps mantra of teamwork and collaboration. One-off automation that is too verbose or specific to a certain condition won’t apply well across groups.

3. Automate Stuff That Doesn’t Change Much

Next, automate the infrastructure that isn’t prone to change. These are fairly reliable things that you’re sure will be part of your systems for the foreseeable future. Because if a component does end up having to be updated often, supporting the automation could be more hassle than it’s worth. “Don’t trade fixing problems for fixing automation,” said Laffey.

4. Start Small

Here’s some sage advice applicable to most new projects with a big scope—start small. Laffey recommended starting by automating the easy stuff that has proven immediate value. These tasks should be modular and do one specific thing, like rebooting a machine or draining a log file. “Automate things in chunks that you can put into a toolchain.”

Too often, teams try to automate everything all at once. But by taking big bites, you can quickly get off track and potentially add to technical debt. If you keep things modular, you’ll find it easier to change and reuse this automation.

5. Share and Be Open

This last tidbit is more of a cultural change—don’t code so that you’re the only one who knows about it! Sometimes, engineers don’t necessarily want the world to know about the automation they create. They might worry about automating their job away. Yet, Laffey said, these worries are misplaced. There will always be more work to do, and automating toil away can free up time to help you focus on more exciting projects.

So, Laffey encouraged DevOps and SREs to be open about the automation they create. Ensure they’re well documented and stored in a centralized repository to allow other departments to reuse your code. This can avoid the duplication of having five different versions of the same script written in different languages within the same organization!

Next Step: Move From Scripts to Industry-Standard Tooling

It can be challenging to argue for investing time and energy into infrastructure automation, especially when engineers are hard-pressed to keep the lights on. Yet, small gains in automation can make huge waves in the long term.

Eventually, said Laffey, you’ll want to move away from using scripts within your toolchain, which he describes as a low-end DevOps maturity. But as you update your process, you’ll want to replace these scripts with more modern industry-standard tools like Terraform or Puppet’s DSL. He recommended slowly revamping scripts in a toolchain as you update them one by one. “Start where you are and avoid a monolithic approach.”

In essence, platform engineering, Laffey explained, is wrapping DevOps principles at a higher level to make them more efficient. And we will likely see an increased emphasis on infrastructure automation as platform engineering gains more mindshare. “It’s going to become a necessity.”

December 12, 2022
Codenotary Extends Dynamic SBOM Reach to Serverless Computing Platforms

Codenotary has extended the reach of its platform for automatically generating software bills of materials (SBOMs) to serverless computing platforms running software constructed using functions.

Codenotary CTO Dennis Zimmer said because serverless apps are dynamically created, it’s not possible to generate SBOMs using traditional approaches. The TrueSBOM platform makes it possible to create an SBOM in real-time by adding one line to the source code of any application. The TrueSBOM for Serverless edition of the platform now extends that capability to the serverless computing frameworks made available in the cloud by Amazon Web Services (AWS), Microsoft and Google.

That approach makes the SBOM a part of the application itself rather than a text file that is stored separately, he noted. Each time an application is updated or a scanner discovers a new vulnerability, a new SBOM is automatically generated, added Zimmer.

Awareness of the need for SBOMs has skyrocketed since an executive order issued by the Biden administration made it clear that federal agencies would require them from software providers starting next year. Many enterprise IT organizations are likely to follow suit as part of a larger effort to better secure software supply chains in the wake of a series of high-profile cybersecurity breaches.

Most internal DevOps teams already have a good handle on what software components are used within the applications they deploy. The issue is that the organizations that use that software can’t easily verify what components are being used, noted Zimmer. That’s problematic because an organization may prohibit deployment of a specific software component because of a known vulnerability. TrueSBOM allows organizations that use an application to maintain control over their software environment regardless of what software artifacts are used to build closed or open source components, Zimmer added.

It’s unclear how most organizations will operationalize SBOMs now that more of them are being created. Ideally, organizations should be able to approve only software with components that have been verified as secure.

As SBOM mandates become more stringent, the number of application providers that are anxious to comply with rules for securing software supply chains should increase. The issue now is finding a way for both the developer and consumer of that software to streamline a verification process that, in its current form, is too cumbersome to manage effectively. As a result, many organizations are now putting together dedicated teams made up of cybersecurity professionals and software developers to manage SBOM processes, said Zimmer.

Of course, there is a massive amount of code that has already been deployed that today doesn’t show up in an SBOM. While many emerging applications—created using artifacts such as functions and containers—are likely to be increasingly instrumented to dynamically generate an SBOM, the number of legacy applications that might need to be similarly instrumented is several orders of magnitude greater. As a consequence, the amount of effort required to generate SBOMs for every application in use might be greater than teams first anticipated.

December 9, 2022