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: Engineer jobs are being cut, cloud infrastructure is using too much energy, and Intel’s 802.11be silicon is alive. (more…)
For several years, we have witnessed widescale cloud adoption as a software infrastructure growth and maintenance strategy. Spending on cloud application services (SaaS) continues to grow as monolithic applications are replaced by microservices-based apps and monoliths become relics of the past. In 2021 alone, companies spent $410.9 billion on public cloud services, and Gartner expects this number to rise by 20.4% in 2022 to reach $494.7 billion. But as this movement continues to evolve, engineering leaders preparing their cloud migration strategy must be up to speed on the latest key trends.
For companies migrating to the cloud now, the process is no longer a simple transition from on-premises to remotely hosted servers. Cloud service providers now offer a wide variety of options, and companies run the risk of overspending in the cloud marketplace.
A lack of clarity of their business and product needs or submission to shiny object syndrome can drive companies to spend on non-essential services, especially during migration. It is easy to fall into this trap; companies only realize it after they have committed and try to undo the damage by reversing the process.
Although many public cloud providers offer pay-as-you-go pricing, companies often purchase more services than they use. When companies are unclear about their objectives, such expenditure is more extravagant than the utility. This awareness of cloud spending has encouraged companies to take stock of their needs and expenses, and when they do not add up, to consider partly shifting back to on-premises.
Not yet, but gone are the days of mindlessly unloading entire infrastructures into the cloud. Increasingly, companies are aware of the costs of pulling their data from the cloud.
For many, security and control concerns motivate them to keep data on-premises. The public cloud has its benefits, but private storage has its place, too, especially for some components of your software. All in all, on-premises is here to stay, as companies continue to acknowledge and appreciate its value despite their reliance on public cloud environments.
Cloud technologies can potentially deliver faster and better-performing experiences to end users, while innovations are giving rise to new services that cloud vendors can capitalize on. Various use cases are surfacing as companies understand the cloud better and see its potential. They are pushing the boundaries on how they can use the cloud, and cloud service providers are keeping track of the changing nature of the demand.
For example, cloud-based gaming platforms like Amazon Luna are seeing significant growth. The cloud is also of great value to artificial intelligence and machine learning efforts, and these are often intertwined.
The Great Resignation phenomenon also drives some companies towards the cloud. Although some knowledge is needed when moving to the cloud, cloud services offer automation and require less employee supervision in the long term.
The COVID-19 pandemic has also been a catalyst for accelerating cloud adoption, making resiliency a priority. Companies can stay afloat in an emergency if their workloads are moved to the cloud. It comes at a cost, sure, but allows companies to outsource time-consuming responsibilities and focus resources elsewhere. While this was most significant in 2020 and 2021, this logic remains relevant.
Cloud computing is also helping companies improve performance, efficiency and scalability. In addition to AI, the cloud will be instrumental in the development of more powerful augmented and virtual reality apps.
The possibility of these approaches or facilities also motivates companies to migrate to the cloud:
Containerization: The process of compiling and storing a service, along with its dependencies, in a container. Due to their small size, multiple containerized applications can run on a server, allowing for easier and cheaper shipping of the service. According to CNCF’s 2021 Annual Survey, containerization is now a mainstream practice, and Kubernetes, for instance, is a heavyweight in this domain, with 96% of companies employing or evaluating it.
Security: In Q1 of 2022 alone, 90% of data breaches had their origins in cyberattacks. Mindful of this alarming trend, companies are factoring security concerns into their cloud adoption strategies. We are also witnessing a shift in businesses’ approach to security via DevSecOps: Incorporating security as a continuous practice from the beginning of the software development life cycle instead of relegating it to the back-burner until the last moment. Additionally, frameworks like secure access service edge (SASE) and customized cloud disaster recovery strategies are becoming essential elements of cloud adoption.
Sustainability: Sustainability is becoming a key component in most business models. Companies are eager to adopt practices and models that reduce their carbon footprint. This impetus is also emerging from business partners and investors who are beginning to employ sustainability as a critical factor when deciding which companies to work with. When a cloud migration is planned carefully, chances are that you will retire certain services in your infrastructure and make decisions about what to migrate and what to retain. By optimizing your migration strategy, you are likely to only run and pay for the services you need, ensuring that your energy expenditure is under control.
Edge computing: Edge computing, a $176 billion market in 2022, emphasizes the importance of building data centers locally; i.e., closer to where they are needed for storage and computational purposes. It solves any bandwidth and latency issues. Improved security is another added benefit of this practice. Edge computing has a bright future as it attempts to compensate for some of the pitfalls of using centralized servers in the cloud.
Cloud-native applications: Cloud-native applications are easier to work with on the cloud, as they are designed and built on the cloud itself, not rearchitected to ensure compatibility with cloud services. When compatibility is not a concern, they can leverage various benefits offered by cloud services. As a result, scalability, flexibility and resilience are built into these applications. With cloud adoption, companies are increasingly in favor of cloud-native applications. This subsequently informs their migration strategy as they decide which services to retire, rearchitect or build anew once the actual migration is complete.
Hybrid computing is on the rise as it leverages the public and the private cloud to deliver maximum benefit to companies with little to no compromise. The public cloud offers scalability, flexibility and speed, while the private cloud provides cost-effectiveness, security and compliance with regulations. While sensitive data can rest on the private cloud, frequently accessed data can be stored in public servers like AWS and Google Cloud. Investing in a hybrid cloud strategy from the point of migration itself can go a long way in giving companies access to the best of both worlds.
Similar to a hybrid cloud environment, a multi-cloud strategy where companies distribute workloads across multiple clouds put some control into the company’s hands and ensures additional flexibility. By working across cloud services, companies can pick and choose which services are most compatible with their application’s components. These can include services offered by different cloud providers.
Serverless cloud environments: Cloud vendors like Amazon, Microsoft and IBM are pushing serverless cloud services. Although these continue to rely on servers (despite the name), companies don’t rent servers or pay fixed charges. Instead, the storage and bandwidth infrastructure scales with the software as and when it requires it. Companies do not need to concern themselves with technicalities and can focus on innovation and improving their existing applications. An added advantage is the provision of safe testing environments that encourage developers to tinker with cloud services and develop solutions for potential failures or outages. Serverless cloud solutions are also beneficial for smaller companies that need not invest large amounts of capital to ensure growth.
Partnerships: To meet the soaring demand for cloud services, partnerships among cloud providers are also on the rise. By partnering with other service providers, companies can offer more services by leveraging the resources and reputations of one another while strengthening their competitive edge in the cloud market.
Industry optimization: Cloud adoption is not limited to software companies. Businesses across industries like healthcare, finance and retail are migrating their infrastructures to the cloud. This variety in demand has encouraged providers to customize their services to meet the specific requirements of each industry. Often, these include regulatory compliance needs in these sectors.
The cloud is only getting bigger and better. You can develop a well-curated transition strategy with the knowledge of current cloud migration trends. Additionally, identifying your requirements at an early stage will go a long way in leveraging the cloud to your advantage.
Over the years, moves to the cloud have happened in several different ways and at various speeds. The reality is that today most enterprises are spending massive amounts on their cloud environments, and many teams are struggling to contend with the governance implications of this reality.
Fundamentally, teams struggle with an either-or proposition: Either they give development and engineering teams free rein in terms of how they use cloud models, and, in the process, they leave the business exposed to a wide range of risks or they try to enforce central controls and restrictions on cloud usage and, in the process, stifle speed, flexibility and innovation.
Teams are struggling with cloud governance in general, and one particularly vexing aspect of governance relates to cloud cost management. Quite simply, the procurement models and approaches that worked in the days of on-premises data centers simply don’t cut it today. At all.
For these reasons, FinOps is emerging as a necessary discipline. At its root, FinOps is about establishing the people, process, and technology for establishing financial accountability in pay-as-you-go cloud environments.
Here’s how the FinOps Foundation defines it:
“FinOps is an evolving cloud financial management discipline and cultural practice that enables organizations to get maximum business value by helping engineering, finance, technology and business teams to collaborate on data-driven spending decisions.”
Recently, I started preparing for the FinOps certification, and in the process, I have had the chance to talk with quite a few practitioners. Along the way, I’ve heard several misconceptions about the discipline. I’ll list and dispel a few of the most common myths in the following sections.
Myth: FinOps is a Buzzword, not a Discipline
While the term may still be new to some, the need for FinOps is clear, real, and not going anywhere. Consider that in a survey of more than 800 professionals, the FinOps Foundation found FinOps team sizes grew 75% in the last 12 months, and respondents are expecting 50% more growth in the next year. Today, the FinOps Foundation has more than 5,300 members. Further, on any given day, a search on career sites for roles specifically referencing FinOps will typically yield hundreds of opportunities.
Myth: The Sole Goal of FinOps is Saving Money
More than just tracking and controlling spending, FinOps offers a way to optimize spending, so each dollar invested ultimately yields the most business value. Rather than simply helping save money, FinOps is about making money.
FinOps teams should advocate and lead with value-based discussions rather than focusing on cost. For example, if additional spending on a certain cloud service increases marginal value, FinOps teams help justify that additional investment.
FinOps helps teams reduce wasted spending, but it also enables teams to invest more in services that allow the business to innovate, adapt, and scale. Ultimately, it offers teams a way to capitalize more fully on the advantages of cloud pricing models.
Myth: FinOps Teams are Responsible for FinOps
To be successful, organizations need to build a central FinOps team. These teams establish guidelines and best practices and facilitate unified reporting and visibility. However, FinOps doesn’t start and end with a single team.
Those that succeed with FinOps are the ones that effectively break down silos. Individuals from leadership, finance, operations, development, and more all have a role to play. In a FinOps-driven organization, a range of teams collaborate, and in the process, they all benefit. For example, development teams can innovate more quickly and make more intelligent, data-driven decisions around balancing speed, quality, and cost.
Through FinOps, everyone takes ownership of cloud usage. Cross-functional teams work together to establish more effective management of cloud vendors and rates. Ultimately, rather than creating conflict, friction is reduced. The end goal is to establish alignment around business objectives.
Myth: FinOps Teams Stifle Innovation
With traditional procurement models, central teams retained visibility and control over expenditures. While this would add layers of time and effort to purchases, this was accepted as a worthwhile tradeoff.
Part of the reason for FinOps has come into existence is that it enables teams to break away from the rigid, centrally controlled procurement models that used to be the norm.
Rather than having a finance team that acts as a central gatekeeper and bottleneck, FinOps enables teams to fully leverage opportunities available for automation in the cloud. Compared to rigid, monthly, or quarterly budget cycles—and being blindsided by cost overruns long after the fact—teams move to continuous optimization.
Real-time reporting and just-in-time processes are two of the core principles of FinOps. Fundamentally, FinOps is about removing obstacles, and the focus is on enabling development teams to speed up their ability to deliver new features and capabilities.
In the cloud, the reality is that teams can spin up a cloud resource with the click of a mouse. FinOps is about bringing real-time visibility to teams so, along with this instant access, there can also be informed decision making and ultimately accountability—all while fostering agility.
Myth: FinOps is Only for the Largest Enterprises With the Biggest Cloud Budgets
Clearly, the larger the business’ cloud investments, the larger the stakes. In addition, the larger investments, the bigger the problems that silos between technology, finance, and procurement can create.
The goal for FinOps is to establish the people, processes, and technologies that enable more intelligent decisions about cloud investments. Ultimately, FinOps enables teams to ensure that each dollar spent in the cloud is delivering the most business value. Given that context, it is clear FinOps is invaluable for any organization making investments in cloud services. This is particularly true as organizations become more reliant on more cloud vendors and service types and more internal teams begin to access services.
Establishing a strong FinOps practice can support growth in cloud investments while equipping teams to ensure better those bigger investments will yield maximum business value.
In my experience, it seems that most organizations take on the creation of a FinOps practice after encountering significant issues, such as massive cost overruns or major snafus that impede operations. It is far better to make this move proactively before issues and obstacles arise. Further, the sooner the move is made, the sooner the business benefits.
As organizations’ investments in cloud services continue to grow, FinOps is becoming an increasingly vital discipline. FinOps offers teams a way to make more informed cloud investments and ultimately ensure those investments yield maximum business value. Consequently, FinOps represents a key aspect of cloud governance, which also requires teams to ensure security, compliance, and operational policies are constantly adhered to.
Quality assurance is a universal concern, especially when it comes to application development. Enterprise applications are faster and more reliable than ever before. However, in addition to performance, application developers also must consider data security, regulatory compliance and cost-effectiveness, among other things. Organizations are embracing quality engineering (QE) as a foundation to create a software quality culture to address these challenges. Creating a quality engineering or TestOps environment is not simple, especially when QE departments must test for hundreds of applications across multiple enterprise environments. Whether it is a solution provider or a multinational corporation, applications often need to be tested across platforms, industries and geographies.
TestOps encompasses a broader concept than just QE. With TestOps, there are testers and engineers using automated and manual testing to validate software for flawless application performance. In enterprise DevOps, the TestOps team serves as the bridge between development and deployment since they have a good understanding of the applications and a better perspective on the context and variables that can affect performance.
Continuous testing is an integral part of any software development cycle. Quality engineers must be brought in early as part of Agile development to keep development on track and head off any problems that could escalate or become harder to resolve later. In Agile, testing becomes more crucial and frequent to ensure flawless performance.
It pays to think horizontally when setting up a TestOps approach. For example, testing should be performed across different vertical environments such as media, manufacturing and finance. The goal is to create a test environment that can accommodate various industries.
In the age of SaaS and universal data access, it is essential to test across multiple platforms. In addition to ensuring enterprise performance, mobile web and remote data access must be tested. For streaming services, it is vital to test across mobile platforms, over-the-top (OTT) platforms such as Roku, Apple TV, Android TV and Fire TV, and even gaming consoles like PlayStation and Xbox.
When shipping software updates, geography matters (especially when shipping across time zones), as one may never know when the software will be used or have control over the environment where they plan to use it.
For instance, consider the challenges a leading mortgage lender faced with mobile application testing and how geography was a factor. First, Google Analytics was used to assess specific device and user requirements and ascertain performance in various parts of the United States since different regions use different carriers. Testing was then done across mobile platforms such as iOS, Android and combinations and across carriers since most banking and mortgage applications required one-time passwords (OTPs) and SMS-related capabilities. Further tests were implemented for new identity authentication strategies such as biometrics and facial recognition. Finally, performance testing by geography was conducted to determine whether a new feature or version would create issues.
Localization testing is important since every region and every country has unique compliance issues and laws. To ensure proper localization, it is essential to perform complete testing, including lower environments and production systems.
In any TestOps environment, the philosophy of continuous testing should already be part of the design environment, including understanding the nuances of production. Release readiness does not mean there are only a few known bugs in certain regions. It means the application has been tested for compliance in every geography where it could possibly be utilized.
Testing application performance in specific industry settings brings along its own set of unique challenges. In manufacturing, for example, each sensor in an IoT device must be modeled against a conformance specification to determine if it can be automated using simulations. In media, one needs to test for different platforms, content management systems and business workflows.
To accelerate time to market, one would want to support a dual-shift development lifecycle to gauge the consumer experience and get continuous feedback and also need a test environment with multiple automation tools such as Selenium, Appium, Cypress, Tricentis, UiPath, Test Complete and Winium.
Artificial intelligence (AI) plays a larger role in testing, shortening time to market, and ensuring superior quality software. AI-driven test tools are optimized for domain-specific applications, such as testing for industries like media, manufacturing and fintech. AI can fill in the gaps to achieve optimization and offer a quicker turnaround with limited manual intervention.
Any organization cultivating a TestOps culture needs to have specific technologies and tools in place. When assessing your testing technology stack, it is important to create an end-to-end testing ecosystem. This means the environments must be inclusive and capable of incorporating testing for unique applications, environments and scenarios. To support the needs of today’s Agile application development environment, one must plan for an agile testing infrastructure to keep development on track.
When it comes to realizing the promise of 5G, we’re still a few years away. Under the hood, though, the rollout of 5G infrastructure and the new applications 5G will enable—from AR and VR to new drone capabilities and beyond—will drive dramatic changes in infrastructure demands, starting with the public cloud.
In the 5G era, many of the applications that will become possible and take advantage of this network infrastructure will require a tremendous amount of data to be moved and processed—whether for a connected car, video surveillance with real-time analytics, or AR/VR—so much so that the data needs can’t really be solved at the responsiveness that these applications will demand from the centralized public cloud as we know it. As 5G creates a new ecosystem, a lot of these applications are going to be built in new ways and rely on the attributes of edge clouds: Edge computing delivered as a cloud-like service. Underpinning it will be cloud-native architectures and other highly automatable and flexible infrastructure to help make it a reality. Let’s take a look at some of the key elements.
SaaS companies building applications in the public cloud today are used to self-service, elastic infrastructure. You don’t have to think about hardware, you pay per use, there are APIs to take advantage of, and most importantly everything is highly automatable and flexible. More than likely, you need only think in terms of a handful of centralized locations as you build—a site on the west coast, one on the east coast, one or two in Europe or Asia.
In the 5G future, that will likely no longer be the case. Many new, revenue-generating services will depend on low-latency, high-bandwidth capabilities that enable applications and data processing to get closer to the user or device. Everything from industrial applications, IoT, to immersive infotainment (virtual and augmented reality) to telemedicine and more will be able to take advantage of the 5G network and edge-compute processing to deliver new capabilities and experiences.
Services like these depend not only on connectivity but also on the ability to gather data, process it, and more importantly, move and act on it at very high speeds.
In this new world, you still want the same things from your infrastructure—it needs to be elastic and capable of scaling up and scaling down. And reliability, automation, and agility (the ability to iterate and deploy quickly) become even more important. And it needs to be available and running in many, many more places in order to be close to the customers and devices you are serving. You’re not thinking about three locations across the globe or two or three across the U.S. Instead, you may be thinking about a couple of dozen in one metro area alone. A whole new kind of compute environment has to be built around that, as well as a cloud infrastructure environment.
5G environments will require very flexible infrastructure that can be highly automated, repurposable, and usable in very generic ways. If you are building metro, point-of-presence data centers all over the country, it is not cost-effective to use highly specific infrastructure for each application in each site; it is too limiting in flexibility and too onerous to manage at scale.
One aspect of the infrastructure challenge is that service providers still rely in part on monolithic, traditional applications that tend to run in physical or virtualized environments to make them deployable, controllable and able to be automated. But newer applications are being designed with a different technology stack based on containers.
With applications that live in both areas, flexibility across VMs and containers is a must. As a result, rollouts of 5G will employ a multimode infrastructure, combining both virtual machines and containers in order to support both legacy and modern applications. The goal: Easy automation everywhere.
Virtualized and container environments will need to live and operate in concert with one another. They both require automation, but because each has its own needs it’s important to choose a technology stack and approach that will incorporate and work with both.
While virtual machines and virtualized network functions (VNFs) are more prevalent today, that won’t remain true for long. As carriers move to microservice architectures that drive continuous improvement and speed time to value, adoption of CNFs is growing.
Since it is still early days for 5G use cases, architecture flexibility will allow carriers to pivot toward any killer apps that emerge. Data-centric infrastructure that can deliver both performance, agility and flexibility is essential.
As we look out at the possibilities for 5G, it’s helpful to think back to the early 1990s. With AOL dial-up and a 2400 baud modem, you could email, surf the web (though it was painfully slow) and play a few games. The advent of broadband ushered in entirely new applications and use cases like e-commerce and media streaming and drove the infrastructure changes to support them. 5G presents the same type of potential for sea change that will open up a whole new world of innovations for the consumer and the enterprise.
California voters passed the California Privacy Rights Act (CPRA) in November 2020. It replaces the 2018 California Consumer Privacy Act (CCPA) and is often described as a cousin to the EU’s GDPR law. The law applies to all for-profit organizations within the state. It also requires compliance from anyone doing business in California or collecting data from the state’s residents.
Since the CPRA focuses on data protection, it applies to developers who deal with customer data or develop websites handling customer data. Building good-looking apps and websites that deliver a great user experience is no longer enough; data privacy must also be part of the equation.
With that in mind, let’s look at everything developers need to know about achieving CPRA compliance.
Here are the main compliance points organizations need to adhere to:
Before or during consumer data collection, organizations must disclose:
Organizations mustn’t keep personal or sensitive information longer than necessary to achieve the disclosed purposes.
These are just some of the compliance checkpoints. For more details on the CPRA responsibilities for businesses, visit the Californians for Consumer Privacy website.
CPRA compliance is costly, but non-compliance can lead to even heftier penalties. The California Privacy Protection Agency (CCPA) is a new agency responsible for enforcing the law. It will give out fines of $2,500 for inadvertent non-compliance and $7,500 for intentional non-compliance. The penalties will increase significantly for abusing data belonging to persons under the age of 16.
Apart from financial losses, non-compliance is risky from a reputational and consumer trust standpoint. In the event of a data breach, these factors may even be more damaging than the fines.
App and web developers have long prioritized deadlines, user experience and other factors over security. This is because they tend to focus on elements that improve engagement and keep users coming back. The CRPA puts a significant limit on data gathering, not only for customers but also for employees. That significantly changes a developer’s approach.
The new law requires developers to take a privacy-first approach throughout the software development life cycle (SDLC). This requires a complete mental shift for most developers, and it will take time to attain. Security is no longer a client request; it’s a mandatory requirement.
Security, privacy and transparency must become focal points for software developers. These elements should influence every decision they make throughout the SDLC.
For existing systems, the CPRA means operational and system updates relating to data gathering and storage, security and governance. Developers will have to adjust systems to gather the bare minimum of data, as the law encourages.
Data anonymity capabilities are also required. Data that isn’t crucial for app or website functions should be anonymized to reduce the risk of a data breach.
Developers should focus on creating apps that:
Gap analysis is the process of determining whether the current system satisfies the desired or mandated requirements. A gap assessment will give developers a clear picture of any existing compliance gaps. For non-existing systems, a gap analysis will help determine how the new system can fulfill requirements.
A gap assessment will also determine whether the CPRA applies to your organization. For instance, if your organization doesn’t collect consumer data, the CPRA may not apply to you.
Reaching CPRA compliance can be a long process, as developers have many requirements to meet. Doing everything at once with no clear plan is a recipe for failure. Instead, create a compliance roadmap with target dates for meeting each requirement. Follow the roadmap rigorously, but also leverage your company’s existing efforts to reach compliance.
Existing efforts may include significant changes like raising the cybersecurity budget. They may also include smaller implementations such as a VPN for remote workers or stricter access control.
Privacy notices to customers are an integral part of the CRPA. The law requires that privacy notices are updated at least once every twelve months. Businesses can no longer set-and-forget their notices.
App developers must identify the existing notices in the system and develop new ones that are in line with the policy changes brought by the CRPA. Notices for employees, job applicants and others must not be forgotten during this process.
Not all data has the same value. Consumer data and confidential company documents are examples of sensitive data. Developers must work with other IT employees to separate the sensitive data and provide additional security to ensure its confidentiality.
Some additional security solutions are data encryption, restricted access, two-factor authentication and strong passwords.
When it comes to cyberthreats, you can never be 100% secure, even if you follow all the best practices and regulations. That’s why having additional help from automated logging and testing software is necessary to maximize security.
Develop a process for continuous self-monitoring and quality assurance. Automated penetration testing is a great way to find holes in your system. It’s also very affordable.
The CPRA was instituted in November 2020. The law requires all for-profit businesses in California to comply with data protection standards. Other states throughout the US are also implementing the same or similar legislation to protect consumer data.
Now is the time to reevaluate your data security practices. Developers must take a privacy-first mindset and start thinking about security implications throughout the entire software development life cycle.
Technology is transforming every aspect of industry, and digitalization and automation have flourished in the past few years. DevOps has established itself as an indispensable software development methodology for successful digital transformation.
According to a recent market survey, the DevOps market will exceed $20 billion by 2026, growing at a CAGR of 24.7% from 2019 to 2026. DevOps has facilitated rapid and dependable software development, delivery, improved quality and higher customer satisfaction.
DevOps, too, is continuously evolving to meet the changing demands of the corporate environment. Let’s look at the future of DevOps and the trends you should expect to see.
DevOps teams will see a rise in the adoption of serverless architecture, mainly because of the massive capital and operational costs of server infrastructure. Numerous DevOps groups are working with modular components offering an overview of the pipeline. Moving these modular components to serverless architecture will empower groups to mitigate a few pieces of errands identified with pipeline architecture and focus on deployment and development of the product.
Serverless computing streamlines overall DevOps operations, including the complete software life cycle, from development to deployment, testing and maintenance in one place. Also, serverless computing reduces the developer’s workload by taking care of server maintenance, such as cloud monitoring and system updates. Other prime USPs include flexibility, reliability, speed and cost-efficiency.
Microservices architecture has been gaining popularity as an alternative to traditional monolithic architecture in the IT industry, and this trend is expected to continue. Microservices architecture is a pattern of organizing computer systems into segments that can scale on demand. A microservices architecture pattern is the next evolution of service-oriented architecture (SOA) that structures an application as a collection of coupled services. If one piece of the application fails, microservices make it easy to identify and contain the issue without disrupting the whole application.
DevOps and microservices architecture enable decentralized teams to innovate rapidly, maintain control over their tech stack and standards, track performance metrics, supervise the development and release cycles and reduce overall consumption time by achieving shorter software release intervals.
To keep up with the demand for new applications and features, many organizations have turned to low-code/no-code development to deploy applications swiftly. Adopting a low-code approach with DevOps is a game-changer. It enables developers to experience higher agility and gives the organization a competitive advantage in the fast-paced, demanding software market.
Low-code applications allow non-technical ‘citizen developers’ to contribute to software development with the help of visual interface integration. In addition to end users, developers and DevOps engineers are set to play a crucial role in this trend, using low-code platforms and tools that offer drag-and-drop elements and other extensions. These low-code application development tools support every aspect of software development, including app ideation, analysis, software design, code development, quality assurance, deployment and documentation.
Many large enterprises are integrating and automating security into DevOps processes. The transformation from DevOps to DevSecOps is expected to gain even more momentum in the future. According to a forecast, the DevOps market size is expected to reach $5.9 billion by 2023 at a CAGR of 31.2% during the forecast period.
More companies will embed security controls earlier in the software development cycle to ensure application security. Tools and frameworks will simply integrate with CI/CD pipelines and testing tools will see a rise in 2022. DevSecOps empowers developers to consistently track, monitor and remediate security defects during the various stages of development while improving the speed of delivery and quality.
Kubernetes is an open source container orchestration platform emerging as an infrastructure trend on the operations side. Kubernetes will expand further into the software development space in 2022 and beyond. It will ease the task of starting a local Kubernetes cluster on a developer’s machine. Kubernetes security is expected to take center stage as well, through infrastructure-as-code (IaC) scanning.
GitOps is a Kubernetes-related infrastructure trend that allows developers and IT operators to use Git to manage clusters and deliver efficient, secure applications without misconfigurations. It automates releasing incremental updates, and consistent delivery will enable developers to build, test and deploy software rapidly.
Artificial intelligence and machine learning have already transformed the way businesses operate nowadays. In 2022, it is anticipated that AI/ML will further streamline and accelerate every phase of the SDLC. It enables DevOps teams to enhance their performance through intelligent automation, improving feedback and managing alerts.
Advanced analytical methods like predictive analytics are becoming increasingly important as the market evolves. AI can enable proactive investigation of the DevOps pipeline to identify problems and offer possible solutions. AI and ML integration also enable deep learning, data mining, statistics and modeling, becoming an integral part of your business’ workflow.
DevOps continues to evolve and pivot to drive significant IT transformations that directly bolster business goals and objectives. It will assist in enhancing the company’s ability to design, produce, launch and maintain high-quality software solutions. The above trends will help organizations move rapidly beyond automation, focusing on continuously improving outcomes. These trends are catalysts for creating a regular and dependable release pipeline and building better communication between development, IT and business teams.
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, a remote/hybrid work special: Bribes to relocate you, Fridays are forgotten, and big tech firms stop building offices. (more…)
Recent security incidents have the industry buzzing about the lack of knowledge about code dependencies, attacks on the software supply chain, software bills of materials (SBOM), digital signatures, provenance, attestation and the like. The fact is, every time a new vulnerability appears a lot of time and effort is required to detect not just when, where and how the vulnerability occurred, but also to measure the real impact on the applications and services that are running in our environments.
What if we had a way to enumerate all the software components we used and produced that could be distributed and consumed easily? This is the problem SBOMs are trying to solve.
An SBOM is simply an artifact containing a comprehensive list of package dependencies, files, licenses and other assets that, together, make up a piece of software. Think of an ingredients list, but for software.
The NTIA defines an SBOM as a formal record that contains the details and supply chain relationships of various components used in building software. These components, including libraries and modules, can be open source or proprietary, free or paid and the data can be widely available or access-restricted.
This concept is nothing new, and bills of materials (BOMs) are a common, existing part of industrial processes. They are very similar to a list of ingredients, although a BOM usually includes the concept of hierarchy, as well. Every component is broken down into a list of subcomponents, each of which also includes their own BOM.
In SBOMs, the pieces are commonly abstract libraries, modules, binaries, compilers, files, etc., and they usually include licensing information (Apache 2.0, GNU, BSD, etc.) and additional metadata.
SBOMs might seem new, but the open source community realized the need for such a thing and created SBOMs more than 10 years ago. The Software Package Data Exchange (SPDX) standard was created in 2010 to communicate SBOM information including components, licenses, copyrights and security references.
In recent years, the issue has come to the fore due to the increase of attacks related to the supply chain. Here’s a short timeline.
And this is just the beginning. 2022 is becoming a turning point in how the industry is approaching SBOM and software supply chain security challenges.
An SBOM applies to any software component, either external or internal, open source or proprietary files, packages, modules or shared libraries used in the construction of software products. This includes firmware and embedded software, too. Hardware might take part in the distribution or execution of software (network equipment, cryptographic devices, chips, etc.) but is not considered part of an SBOM, although standards like CycloneDX support devices as a type of component.
In an ideal world, every software company would attach an SBOM to each deliverable, and everyone would have full visibility into the components used in the software. That would enable knowledge of exactly which vulnerabilities are impacting that software.
But we are not in that ideal world.
● Development dependencies. Every time a developer includes a third-party dependency (either open source or an internal component), it is often adding transitive dependencies – the modules or packages that the dependency itself is using. So, a detailed SBOM would enable visibility into those transitive dependencies, as well.
● Software applications or packages. When an application is distributed, the SBOM would help the consumer quickly identify the application version, helper tools that are included in the package and all the pieces that were involved in the build process. This makes it much easier to identify vulnerabilities or troubleshoot issues that might be caused by buggy software dependencies.
● Container images. Container images are basically a filesystem composed of a base image distribution plus a set of additional packages and components added during the build process.
● Hosts. Hosts include, for example, virtual machine appliance images, an AWS AMI and the like. The SBOM would include the base operating system type, vendor, version and a comprehensive list of each package installed in the host, either from the base operating system (e.g., the Linux distribution) or manually deployed from external sources.
● Hardware devices. Examples include a firewall, an IoT device or a mobile phone that is running software.
SBOMs should capture any and all multi-level dependencies. So, for example, if package libfoobar-1.5.3-r3-u8 is part of the SBOM, it should also include each package name, version, license, etc. used to assemble libfoobar-1.5.3-r3-u8, and the components for each of these, resulting in a multi-level tree where each node is decomposed into its dependencies.
It is also important to point out that every time one of these assets changes—every release of a product or even each build—a new SBOM should be created to match the changes for that version.
You need an SBOM for the same reason you need a list of ingredients for food. You can check for the presence of allergens, the presence of animal-based substances (for vegans), chemical preservatives, etc. Certainly, you can eat food without checking the list of ingredients, but you are assuming some risks. The same applies to software: It might be fine to use a dependency for a quick test in a sandbox environment, but you definitely want to know what’s inside when deploying critical services to production or delivering software in environments with strong compliance regulations.
Without an SBOM, you don’t have that visibility. A piece of software becomes an impenetrable black box with respect to the packages and libraries that are used to assemble it.
The availability of an SBOM for third-party dependencies makes it easier to build an SBOM for your software by simply adding your own ‘ingredients’ to the existing list of dependencies. Of course, your software can also be the input or dependency of a more complex product, and consumers might demand the presence of an SBOM as part of their supplier’s requirements.
Knowing which licenses are necessary for the different software pieces is also very important. Otherwise, distributing software using third-party libraries under multiple license types might break the usage terms or force you to make source code public, which can be inconvenient and even get your company into trouble.
Finally, the SBOM is a key element of the vulnerability scanning process. Provided that you have an accurate SBOM and reliable and updated vulnerability feeds from different vendors and sources, it is pretty straightforward to find which vulnerabilities are present in the software. Without an SBOM, the vulnerability scanning software needs to compute and guess; making its own inaccurate version of an SBOM, which might be quite tricky or even impossible for some components.
A good SBOM should allow organizations to answer questions like, “Am I vulnerable to the CVE-2022-22965 (Spring4Shell) vulnerability?” Exploiting this vulnerability requires a set of conditions to happen simultaneously in the host or container running the exploitable Java package:
● Using SpringCore versions 5.3.0 to 5.3.17, 5.2.0 to 5.2.19 or older, unsupported versions
● Using JDK 9 or higher
● Running Apache Tomcat as the Servlet container
● Having the library packaged as WAR
● Using the spring-webmvc or spring-webflux dependency
Most of these conditions can be checked for in the contents of a comprehensive SBOM, making it easier to assess the risk in your environments by focusing on fixing the exploitable applications first.
Currently, generating SBOMs is complex because there are multiple competing standards, distributions, etc. that make adoption slower than desired.
Many tools exist that can help you create an SBOM for a piece of software. Before you even consider producing an SBOM, it is critical that the build process is completely automated (Level 1 in the SLSA framework) and SBOM creation is integrated as part of the build pipeline.
Next, these are some example executions and outputs of open source tools and the corresponding SPDX or CycloneDX (truncated) SBOM, which are two of the most common standards.
Syft can generate an SBOM in SPDX or CycloneDX format from a filesystem or container image, and it is embedded in Docker by default using the docker sbom command.
$ syft neo4j:latest
✔ Parsed image
✔ Cataloged packages [376 packages]
NAME VERSION TYPE
CodePointIM 11.0.15 java-archive
FastInfoset 1.2.16 java-archive
…
util-linux 2.36.1-8+deb11u1 deb
wget 1.21-1+deb11u1 deb
zlib1g 1:1.2.11.dfsg-2+deb11u1 deb
zstd-jni 1.5.0-4 java-archive
zstd-proxy 4.4.8 java-archive
When using the -o flat to set the output to spdx-json format, it will produce a document like:
$ syft -o spdx-json neo4j:latest
✔ Parsed image
✔ Cataloged packages [376 packages]
{
“SPDXID”: “SPDXRef-DOCUMENT”,
“name”: “neo4j-latest”,
“spdxVersion”: “SPDX-2.2”,
“creationInfo”: {
“created”: “2022-06-23T10:09:26.751733Z”,
“creators”: [
“Organization: Anchore, Inc”,
“Tool: syft-0.48.1”
],
“licenseListVersion”: “3.17”
},
…
“packages”: [
{
“SPDXID”: “SPDXRef-fd9f083cc189cf0c”,
“name”: “CodePointIM”,
“licenseConcluded”: “NONE”,
“checksums”: [
{
“algorithm”: “SHA1”,
“checksumValue”: “50a6f2c46702b14cb129aac653d9abfcdc324363”
}
],
“downloadLocation”: “NOASSERTION”,
“externalRefs”: [
{
“referenceCategory”: “SECURITY”,
“referenceLocator”: “cpe:2.3:a:oracle-corporation:CodePointIM:11.0.15:*:*:*:*:*:*:*”,
“referenceType”: “cpe23Type”
},
…
{
“referenceCategory”: “PACKAGE_MANAGER”,
“referenceLocator”: “pkg:maven/CodePointIM/CodePointIM@11.0.15”,
“referenceType”: “purl”
}
],
“filesAnalyzed”: true,
“licenseDeclared”: “NONE”,
“sourceInfo”: “acquired package info from installed java archive: /usr/local/openjdk-11/demo/jfc/CodePointIM/CodePointIM.jar”,
“versionInfo”: “11.0.15”
},
{
“SPDXID”: “SPDXRef-80979ce84b1617b2”,
“name”: “FastInfoset”,
“licenseConcluded”: “NONE”,
…
},
…
],
“files”: [
{
“SPDXID”: “SPDXRef-9e950849d3fbc974”,
“comment”: “layerID: sha256:ad6562704f3759fb50f0d3de5f80a38f65a85e709b77fd24491253990f30b6be”,
“licenseConcluded”: “NOASSERTION”,
“fileName”: “/bin/bash”
},
{
“SPDXID”: “SPDXRef-d1fd1bc48eedeaba”,
“comment”: “layerID: sha256:ad6562704f3759fb50f0d3de5f80a38f65a85e709b77fd24491253990f30b6be”,
“licenseConcluded”: “NOASSERTION”,
“fileName”: “/bin/cat”
},
…
],
“relationships”: [
{
“spdxElementId”: “SPDXRef-a124711c55c5b5ec”,
“relationshipType”: “CONTAINS”,
“relatedSpdxElement”: “SPDXRef-9f73084aac22b0b3”
},
{
“spdxElementId”: “SPDXRef-a124711c55c5b5ec”,
“relationshipType”: “CONTAINS”,
“relatedSpdxElement”: “SPDXRef-23989aa2a193ea3d”
},
…
]
}
This not only includes the packages but also the files in the image, relationships between the elements, licensing information and more.
The Node.js package cyclonedx/bom allows you to generate an SBOM from a Node project in CycloneDX format. An example output when generating the SBOM from github.com/fastify/fastify looks like:
$ cyclonedx-bom
$ cat bom.xml
<?xml version=”1.0″ encoding=”utf-8″?>
<bom xmlns=”http://cyclonedx.org/schema/bom/1.3″ serialNumber=”urn:uuid:be53de33-6897-49ca-855d-926383866c21″ version=”1″>
<metadata>
<timestamp>2022-06-23T10:03:17.018Z</timestamp>
<tools>
<tool>
<vendor>CycloneDX</vendor>
<name>Node.js module</name>
<version>3.10.1</version>
</tool>
</tools>
<component type=”library” bom-ref=”pkg:npm/fastify@4.1.0″>
<author>Matteo Collina</author>
<name>fastify</name>
<version>4.1.0</version>
<description>
<![CDATA[Fast and low overhead web framework, for Node.js]]>
</description>
…
</component>
</metadata>
<components>
<component type=”library” bom-ref=”pkg:npm/%40fastify/ajv-compiler@3.1.0″>
<author>Manuel Spigolon</author>
<group>@fastify</group>
<name>ajv-compiler</name>
<version>3.1.0</version>
<description>
<![CDATA[Build and manage the AJV instances for the fastify framework]]>
</description>
<licenses>
<license>
<id>MIT</id>
</license>
</licenses>
<purl>pkg:npm/%40fastify/ajv-compiler@3.1.0</purl>
<externalReferences>
<reference type=”website”>
<url>https://github.com/fastify/ajv-compiler#readme</url>
</reference>
<reference type=”issue-tracker”>
<url>https://github.com/fastify/ajv-compiler/issues</url>
</reference>
<reference type=”vcs”>
<url>git+https://github.com/fastify/ajv-compiler.git</url>
</reference>
</externalReferences>
</component>
…
</components>
<dependencies>
<dependency ref=”pkg:npm/fast-deep-equal@3.1.3″/>
<dependency ref=”pkg:npm/json-schema-traverse@1.0.0″/>
<dependency ref=”pkg:npm/require-from-string@2.0.2″/>
<dependency ref=”pkg:npm/punycode@2.1.1″/>
<dependency ref=”pkg:npm/uri-js@4.4.1″>
<dependency ref=”pkg:npm/punycode@2.1.1″/>
</dependency>
<dependency ref=”pkg:npm/ajv@8.11.0″>
<dependency ref=”pkg:npm/fast-deep-equal@3.1.3″/>
<dependency ref=”pkg:npm/json-schema-traverse@1.0.0″/>
<dependency ref=”pkg:npm/require-from-string@2.0.2″/>
<dependency ref=”pkg:npm/uri-js@4.4.1″/>
</dependency>
…
</dependencies>
</bom>
Snyk’s snyk2spdx tool leverages Snyk’s open source API to create an SBOM from your code repositories. Unfortunately, at the time of writing, this repository is outdated and unmaintained.
There are also a number of online tools that allow importing different formats or manually adding components to the SBOM definition and then downloading it. The NTIA also published the “How-To Guide for SBOM Generation“, a collection of simple instructions and guidance on how to generate an SBOM. It is interesting that the guide includes the concept of “completeness assertion” for cases where the dependencies of some components are missing.
Ideally, the vendor of a product should tell us every component and provide it in a digitally signed document to prevent tampering or modifications. But we are still far from this holy grail, and there aren’t many vendors producing and providing this information. It’s a complex process involving multiple tools and pieces, and there are multiple standards for SBOM distribution.
In an ideal world, every vendor would provide a 100% accurate, comprehensive, digitally-signed bill of materials in a common standard. But in the real world, we usually need scanning tools that can produce a ‘guessed’ bill of materials. This is harder, as many components are opaque and it is difficult to discover the dependencies or libraries used during the build.
Still, scanning is necessary, as the SBOM from the vendor might be wrong. The vendor’s build process might be compromised, so some components might be intentionally omitted from their SBOM, which brings us to the following question: Can the SBOM be wrong or inaccurate?
Yes. The quality of an SBOM depends on the quality and automation of the process that builds the SBOM.
It is easy to produce the root level (like the version and details of the software you are directly building) and the first level of dependencies (packages and third-party libraries). It becomes more difficult to do so for transitive dependencies and even harder as you navigate deeper in the tree. Many components might not provide their own SBOM and detecting dependencies can be complex or just plain impossible, like in statically linked binaries with stripped information.
Even with a perfect toolchain and perfect SBOM information during the build phase, an attacker could tamper with the contents of the SBOM (i.e., modify the companion file or artifact at rest) to hide the fact that it contains vulnerable or malicious components. A consumer would then retrieve the modified version of the SBOM and miss these dangerous components.
A common, recommended practice is adding a digital signature to the SBOM artifact to make sure the consumer can verify its authenticity and integrity.
Even worse, it is possible that an attacker could compromise the build pipeline itself and modify the process of creating the SBOM, which would result in a digitally signed but altered list of components.
From a scanning tool perspective, a software component is usually a black box, or the amount of information that can be obtained from analysis might be quite limited, as most of it (like pom.xml or go.mod files) is available during a build but removed in the final deliverable.
An appropriate simile would be analyzing food in a laboratory versus having the list of ingredients from the producer. Analysis or scanning would produce quantitative data (what is observed in the box) versus the provided SBOM which can contain qualitative data and that can be lost or invisible to an analysis.
To minimize the risks of poor quality SBOMs or attacks, it is recommended that organizations use scanning solutions even in the presence of vendor-provided SBOMs.
A vulnerability is a weakness or flaw that an attacker can exploit to bypass security boundaries, get access to a system and more. They are a typical way to attack or compromise the software supply chain.
To find vulnerabilities in a piece of software (or in a running host, a container image, etc.), you need something that matches “known” vulnerabilities with the set of components in your software. This is called vulnerability scanning. And it’s where the SBOM comes into play, as it contains a comprehensive list of packages and versions composing your software.
Then, another big question arises: Where do the known vulnerabilities come from? (Note that vulnerabilities need to be known in advance, you cannot detect an unknown flaw.) Researchers and hackers discover them and they end up in vulnerability databases that can be consumed by humans or computers. There are two main sources for vulnerabilities: Vendors and independent providers.
Vendors can provide feeds for vulnerabilities in their products, like major Linux distributions or package repositories like Go, npm, etc. Vendors have good context around how the vulnerability impacts the product. However, they might also be biased in regard to severity.
Independent providers like NIST, Mitre, the Open Source Vulnerabilities Database and commercial offerings like Snyk and VulnDB collect, analyze and provide information for vulnerabilities. The drawback is the score is objective, without a specific context of how the vulnerability might apply to different products. In some cases, vulnerabilities might not even impact a vendor-specific product version because it is forked or the patch is backported.
Consuming vulnerability feeds can be challenging because different formats and standards exist for vulnerability information exchange, like:
● Red Hat OVAL – An XML format used for Red Hat Enterprise Linux, Openshift, and other Red Hat products and also available for Ubuntu.
● Different JSON feeds like the Debian Security Tracker.
● APIs like OSV allow querying for specific open source package versions.
● Security advisories meant for humans but not for automated processing, like Gentoo security.
● NVD CVE JSON v5.0, an attempt to create a standard CVE format.
● Common Security Advisory Framework (CSAF) – Standardized automated disclosure of cybersecurity vulnerability issues.
● Vulnerability Exploitability eXchange (VEX), which has been implemented as a profile of CSAF.
VEX is interesting, as it allows vendors to provide a kind of ‘negative’ security advisory that says, for example, that a certain vulnerability does not apply to a component because the submodule in the package is not even used in the product.
Another source that can help prioritize vulnerabilities is the CISA’s Known Exploited Vulnerabilities catalog (KEV), an updated list of vulnerabilities with assigned CVE ID, reliable evidence of being actively exploited in the wild and clear remediation (such as a vendor update).
The following diagram describes the full vulnerability management flow:
A typical flow is comprised of a scanning tool that is capable of creating an SBOM by analyzing a container image, host or workload, or directly by consuming a pre-computed SBOM (or both!). The scanning tool then matches known vulnerabilities from different sources (usually the vendor-provided sources for the corresponding Linux distribution, plus generic sources like NVD to report the list of vulnerabilities impacting the software.
You can see an example of matching the Kubernetes SBOM (which is publicly available for each version) with known vulnerabilities from OSV using the spdx-to-osv tool.
The list of detected vulnerabilities can be curated and prioritized with additional information, like VEX (not exploitable vulnerabilities) from the vendor, KEV list or risk spotlight information from Sysdig, which can detect the packages effectively loaded during the execution of the workload. This filters out the packages that are inside a container image but never executed, so they are not exploitable.
Even though there is a lot of buzz around supply chain security and an ever-growing set of tools and products, many of these tools generate SBOMs by analyzing the components and guessing the dependencies.
The optimal approach to generating an SBOM on every upstream component still requires tailor-made solutions for most cases. This translates into incomplete or inaccurate SBOMs, not to mention the different existing formats (CycloneDX, SPDX, SWID) and lack of a standardized distribution mechanism, making wider consumption of SBOMs pretty difficult.
Another problem to consider is that the limitations in the SBOM propagate to vulnerability scanners. For example, a missing package can result in a false negative (an existing vulnerability not being reported) and applying a patch on a custom package version can result in a false positive. In general, any package customization which doesn’t result in a version reflected in vulnerability databases might cause a false positive/false negative issue. And there is no single provider for vulnerability information, nor a single exchange standard. Ideally, every vendor would provide their own source of security advisories, and VEX to allow flawless identification of the existing weaknesses.
An SBOM is a key element in securing the software supply chain and fundamental for vulnerability matching and management. It is becoming more important as software consumers and governments are raising the collective bar on security requirements and software quality for their providers.
At the time of writing, there are still different competing standards, a plethora of tools and a lot of uncertainty; most of the actors are still struggling to get there. But the general consensus is that we need to secure the supply chain, converge on common standards, and make the SBOM an essential part of the build process.
An interesting initiative to follow up to start securing the supply chain is the SLSA framework, which introduces different levels of maturity in the software supply chain, so you can start from nothing and progressively implement different mechanisms to be as resilient as possible, at any link in the chain.
Security concerns and DevOps process issues can stall CI/CD operations. DevOps teams are familiar with the frustrations plaguing their pipelines, whether regulatory or process-based. Operational hurdles are all too common in DevOps pipelines, leading to miscommunication between team members and the broader organization. One of the leading operational issues DevOps teams encounter is permission issues. Permission issues are a seemingly small yet significant roadblock to smooth CI/CD pipelines. Fail to address them and the result is a lack of cohesion between development and organizational objectives.
Here’s how to streamline these processes, boost security integration within the broader CI/CD framework, and maintain robust security postures.
The DevOps life cycle often contains multiple tools, all with different access needs and permissions. As such, this situation is a security nightmare. Jeremy Hess, head of DevRel at secrets management platform Akeyless, called this a “secrets sprawl.”
“The combination of proliferation and decentralization of secrets creates an operational burden, if not a nightmare,” he said. “For organizations that operate in both a cloud-native environment and classic IT infrastructure, a duplication issue is created due to having their own secrets managed with different tools and cloud-native solutions.”
There is also the risk of these tools exposing user credentials and permissions to malicious actors. For instance, configuration tools like Jenkins use plugins to determine access and artifact deployment. Because these tools communicate with other pipeline tools, credential details can often be present in configuration details.
Developer passwords are not visible on the frontend but could accessible from the system backend. Any user with ‘configure’ permissions could request any credential and then inject them into agents. The result is that AWS keys, Git credentials and/or passwords are at risk.
To mitigate this issue, the first step involves deleting hard-coded secrets from CI/CD tool files. Distributing secrets between multiple tool configuration files also reduces the possibility of attack while easing developer and engineer access. Password managers are also a good choice, but validate them for security before implementing a solution.
Access and permission issues often create a lot of frustration among DevOps teams as they are forced to assign blanket access to the majority of users, regardless of members’ roles or job functions. While this situation encourages rapid development, it also creates massive security issues.
Balancing security with CI/CD needs is tough to get right. That’s where the principle of least privilege comes in. Team members receive access to secrets on a need-to-know basis. Note that this principle applies to everything from apps to systems and connected devices.
While most teams put this principle into practice, they make the mistake of leaving their process intact. The lack of access audits creates DevOps frustration, not the level of access. CISOs should regularly involve DevOps teams when reviewing access to mitigate issues quickly.
For instance, embedding a security role within every delivery team will mitigate access-related risks quickly. The security team member will have insights into risk-based access needs and can quickly approve or reject requests.
Creating an access management repository will also remove any confusion related to role-based access. In addition, record time-based and task-based access permissions in the repository. The result is every DevOps team member understands their access paths before projects get started. It allows them time to offer feedback and request one-off access to sensitive secrets.
Review segmentation rules within your systems when assigning role-based access. Often, these rules will have to change depending on delivery timelines. Involving all stakeholders in these discussions is good practice and prevents frustration down the road.
Implementing OTPs and other authentication factors is also a good idea when validating user access to secrets.
Open source software (OSS) projects are essential to industry growth but might pose security risks if access is mismanaged. Zan Markan, developer advocate at CI platform CircleCI, summarizes the problem aptly.
“Often, the company that initiated and that owns a popular OSS project continues to employ the core contributors,” he said. “They will probably be joined by other regular contributors and maintainers that are not part of that company. And then there is everyone else—anyone who occasionally might contribute a fix or a feature.”
As user access grows, security concerns grow exponentially. Enforcing rigid user-based access is unrealistic and detrimental to an OSS project. However, CISOs or other security-focused managers must review whether sensitive secrets are being passed during builds for pull requests. Monitoring permissions—and who can place requests and roles that review them—will ensure a good level of security.
Establishing machine identity is also critical, given the degree of non-human access pipelines face. Authentication can be based on verifying whether client runtime container attributes match the characteristics of the valid container. Once authenticated, role-based access can take over, limiting access to secrets.
It’s also a good policy to destroy containers and VMs after they’ve been used.
DevOps is critical to every organization’s success. Access and permission-related issues are common occurrences, but are easily avoided. Reviewing access and establishing a balance between delivery and operational needs is essential to maintaining a competitive edge.