devopsy.kinsta.cloud

Category: DevOps Practice

Survey Finds Widespread Adoption of DevOps in Mainframe Sites

A survey of IT leaders by the market research firm Global Surveyz found a full 100% of respondents are modernizing their mainframe applications, but the reasons behind and approaches to achieving that goal vary widely.

The research was conducted on behalf of Model9, a provider of tools for migrating mainframe data, and polled 100 companies that have more than 1,500 employees or more and use mainframes. Nearly three-quarters of respondents (73%) are embracing DevOps best practices to manage mainframe infrastructure, with 61% modernizing their mainframe applications. Just under half (46%) also noted they were outsourcing the management of those operations.

However, the survey also found that unlocking the business value of stored data and accelerating innovation are among the top 2022 objectives for 42% and 36% of respondents, respectively. Data protection (89%), cybersecurity and resilience (76%) and cost optimization (52%) are the top priorities.

Tamar Milstein, chief marketing officer for Model9, said that the continued focus on block-and-tackle mainframe management issues suggests there may be a disconnect between IT teams managing these platforms and senior business executives that are looking to drive digital business transformation initiatives.

Nevertheless, a full 91% of respondents said the mainframe still holds the most critical applications for their business, with 62% reporting more than half of their core business applications on these platforms. The use of cloud computing platforms alongside mainframes is also widespread. A total of 61% have a hybrid multi-cloud computing environment already in place. Only slightly over one-third (35%) are using a single cloud to augment their mainframe. Nearly half (48%) are replicating data to the cloud. However, just over half (51%) are storing more than 50% of their data off the cloud.

Model9 is making a case for modernizing these environments by making it easier for mainframe applications to access data stored on less expensive platforms to house data. That approach provides all the benefits of the cloud without having to incur the risks and costs of attempting to migrate an entire mainframe application to the cloud, said Milstein.

Regardless of the approach organizations take toward application modernization, the survey made it apparent just how widespread the adoption of DevOps best practices in mainframe environments is. Many of those organizations are using DevOps practices to add application programming interfaces (APIs) to legacy mainframe applications to make the data residing in those applications more accessible. That approach reduces the technical debt that organizations might otherwise incur as they build and deploy applications on other platforms that might provide similar capabilities to an existing mainframe application.

While there are plenty of organizations that have migrated away from mainframes, there remains a large base of IT teams still running applications on these platforms. Achieving the same level of transaction processing capabilities enabled by a mainframe in a cloud computing environment isn’t yet feasible. There are, of course, organizations that decided they would no longer like to operate a data center at all, but there’s still a substantial number of organizations that will continue to operate mainframes well into the rest of this century.

March 14, 2022
Tackling CostOps When You’re a Developer

The implementation and successful execution of IT initiatives often comes down to developers. From those working with commercial vendors to those working with open source projects, cloud-based software-as-a-service (SaaS) solutions, managed service providers (MSPs) and internal teams, they all play an important role in the successful running of IT and operations teams.

One challenge developer and operations teams face is the huge time barrier between development and follow-on operations. What a developer builds today for an organization may continue to be used decades from now, and will likely be maintained, patched, updated and modified by other developers. Though it’s a point of pride for the developer—who will have likely moved on in their career—it can be challenging for the operations team who has to continue to deploy it year after year.

With more applications than ever before, the traditional role of the developer is changing. Today, developers need to start factoring operations cost containment into their responsibilities.

Opportunity for the Developer

Developers are rarely responsible for long-term business decisions. Once code is out of their hands, they often have little to no stewardship of their work. The business will make critical IT cost optimization and containment decisions about its code, language and toolchain epochs later. Developers focus on the now and the near future. Spending hours envisioning the one winning outcome out of 10,000 possibilities years later won’t get code out the door or achieve the delivery goals of their managers.

However, developers have an often-overlooked opportunity to include the gears to activate cost containment support during initial development. From there, if their work is good, it’ll endure; extended support will eventually be necessary. The first step is to ensure new and modernized applications include solid cloud-native monitoring from the outset. This not only helps DevOps and SRE teams but benefits the entire business, who’ll own those applications for the long term.

Integrating operations-focused monitoring is a top priority for developers. In some cases, an application using platform-managed serverless or orchestrated containerization has no shortage of opportunities to provide developers and operations with detailed performance data.

A developer’s expertise with dependency analysis, code maturity and ease of integration is a great measurement tool to evaluate tool durability. A solution capable of easily combining cloud-native application performance details with infrastructure performance, user experience and operational expense data is even more likely to help developers and businesses manage costs in the long run.

A New Dimension

As cloud-native becomes a mainstream enterprise strategy, cost containment is a key opportunity. To meet the future challenges of application management, leadership is rapidly expanding their definition of application suitability and quality to incorporate all aspects of application ownership. For some teams, cost containment is a new dimension of senior developer maturity.

March 14, 2022
What is DevSecOps?

While traditional development practices have long separated security and compliance, DevSecOps as a series of best practices integrates security into every phase of the DevOps software development life cycle. DevSecOps introduces and automates security in the earlier phases of the software development life cycle rather than bolting it on at the end. The approach saves money, saves time on tedious manual tasks, helps organizations meet regulatory compliance requirements and significantly reduces the risk of critical security bugs being found after an application’s final build. DevSecOps promotes the use of, for example, active penetration testing, security audits and other security tools within an agile development process.

The goal of DevSecOps is to create a collaborative environment between developers and security professionals that enables organizations to build secure code faster and more easily. By emphasizing security from the very beginning of the process, it becomes a priority in the app dev process rather than an afterthought. Over time, developers become more familiar with the common weaknesses in software that today result in more insecure applications being deployed than most anyone really wants to admit. The end goal is to create secure applications by making it easier for developers, security experts and operations professionals to collaborate throughout every stage of application development.

Minimizing Application Vulnerabilities

It may seem tedious and expensive to integrate security into the development process, but it’s become essential for organizations to embrace DevSecOps to minimize the number of application vulnerabilities that cybercriminals might exploit. When applied throughout the development process, scanning and reporting can take place within a matter of minutes rather than holding up deployment at the end of the process to review the entirety of an application.

Leaving security to either the end of the application development process or, worse yet, after an application has been deployed only increases the total cost of ownership. It’s much more expensive to remediate a vulnerability after an application has been deployed than it is to address an issue during the application development process.

Implementing DevSecOps requires organizations to set up workflows that are managed via a continuous integration/continuous delivery (CI/CD) platform. Most critically, developers must understand the role security plays in enabling organizations to identify vulnerabilities as early as possible in the application development life cycle.

Inserting security audits and penetration testing into the development process, for example, helps ensure the security of an application. When changes are made in a project, scanning, architecture reviews and penetration testing can be triggered within the development flow to save time and resources.

DevSecOps Adoption

However, there are many technical and cultural challenges ranging from tool integration to a lack of trust between developers and security teams that can impede the adoption of DevSecOps. Security professionals are tasked with identifying and preventing vulnerabilities in applications. Acceptance test criteria, user designs and threat models should be created by security professionals. The development team then needs to define a code review system to ensure uniformity.

Despite those concerns, the most important thing is to simply get started. Ideally, development and security teams should work together to create a safe application development and software development environment. There is no need to create separate teams or apply different policies.

The biggest benefit of DevSecOps is that it eliminates silos between development and operations. As a result, software engineers integrate cybersecurity processes from the start of the development process. This includes ensuring that every component, configuration item, and installation process is securely patched and documented. This concept of shifting security to the left allows the security team to identify and remediate security threats early on.

In the longer term, however, adopting DevSecOps best practices will ensure security remains a top priority in the wake of a series of high-profile cybersecurity breaches. In short, there is now more focus on DevSecOps with the goal of securing software supply chains.

March 11, 2022
What is MLOps? DataOps? And Why do They Matter?

Let’s look at three distinct disciplines—DevOps, MLOps and DataOps. In 2011, Marc Andreessen famously proclaimed that software was “eating the world.” A little more than a decade later, it’s all but impossible to argue with his premonition as software has embedded itself into virtually every industry.

But now another shift is underway and AI is gobbling up software as we know it. Our emails can finish our sentences for us, connected cars are helping us stay safer on the road and predictive technology is helping minimize supply chain disruptions caused by COVID-19. In the near future, almost every piece of software we interact with will have intelligence built-in, and as AI gains acceptance and new use cases are rolled out, applications will only continue to become more intelligent. The widespread move toward ML-enabled software has the potential to be as transformative and far-reaching as what Andreessen predicted.

But innovation is rarely easy or simple—and intelligent applications are no exception. While conventional software involves one thing—code—and not much else, intelligent software relies on a complex relationship between three interconnected variables or legs of a three-legged stool.

A Three-Legged Stool: DevOps, MLOps and DataOps

Model: The one or more AI/ML models (e.g., linear regressions, rules, deep neural networks, etc.) trained to recognize patterns in data and make decisions are what makes an application “intelligent.”

Data: Most often, a model is trained on historical data and programmed to emulate it. As a result, an application’s behavior depends heavily on the data—the raw input data, labels and features, as well as the new data to which the model is applied and ground-truth for this data.

Code: Code is the language an application uses to function. When used in the context of intelligent applications, the code pillar might refer to business logic, calls to models, receiving outputs, decision making and calls to other data systems.

A Real-World Example

To see how these pillars play out in real life, consider the example of a perception system for a self-driving car. Such systems use data (provided by offline sources and real-time cameras and sensors), models and code to determine myriad ever-changing variables (for example, if there are obstacles on the road, what lane markings look like, how fast a car can safely travel, etc.) While the following illustration is greatly simplified, it outlines the basic steps needed to build and deploy such a system and indicates which pillar each step belongs to.

Regardless of application type, the legs that intelligent applications stand on are always the same: Model, data and code. And if you try to remove any one of them, the application will topple over.

With the three distinct pillars that make up intelligent applications, three distinct disciplines have emerged to keep each individual pillar functioning as efficiently as possible: DataOps, MLOps and DevOps. The rest of this post examines the details that make each discipline distinct and necessary to the model life cycle.

DevOps

Once upon a time, companies used waterfall processes to develop software. The process often moved so slowly that products didn’t realize their potential before they died or were replaced. In 2000, Agile was introduced, allowing developers to work quickly and iteratively in tight sprints where they were constantly delivering. By 2009, Flickr, for example, was the envy of the industry, routinely performing 10+ deploys per day. Companies seeking to increase their own productivity combined software development with established operations principles—and the term “DevOps” was coined.

As the familiar loop graphic below illustrates, the DevOps cycle goes from the planning stages to the creation, testing/verification, packaging, release, configuration, monitoring and then starts over again with planning. Over the past two decades, a host of unique tools have emerged to support individual steps in the DevOps life cycle—helping developers ensure quality by building in continuous integration and continuous testing from the start and helping speed up time-to-market with workflow automation. The DevOps ecosystem is robust, well-thought-out and always iteratively improving.

MLOps

MLOps helps teams move more quickly and efficiently through the model life cycle—a loop that involves six distinct steps, each of which contains unique considerations.

Since MLOps is related to DevOps, businesses sometimes try to adapt the processes used to write conventional software to execute the unfamiliar task of machine learning operationalization. But the approach doesn’t work, as the two disciplines are actually quite different.

MLOps primarily deals with models, not code—and models are quite different from code. For example, model training and testing look very different from code building and testing. (What does “test case” even mean for a model?) And monitoring model performance is completely different than monitoring traditional software. (DevOps looks at things like CPU utilization, latency and throughput, while MLOps looks at model quality, drift and data quality.)

Furthermore, the people that MLOps engineers are building for are quite different than their DevOps counterparts. As one might expect, the primary users of models are data scientists while DevOps generally serves software developers. Most often, MLOps engineers come from a background in ML and data science or software engineers who picked up ML.

As with DevOps, no single all-inclusive MLOps platform exists. Rather, different tools support different individual steps in the model life cycle and provide some amount of workflow automation to speed up processes. Different tools support specific pieces of the ML life cycle—but the ecosystem is still somewhat fragmented. Ideally, MLOps will evolve to offer more DevOps-like tools that work well together and offer more automation. For companies looking to build an MLOps platform, build a suite of supporting tools with speed, safety and automation in mind.

DataOps

We’ve seen very well-defined life cycles for the other two pillars discussed above; however, when it comes to DataOps, the life cycle is still being defined. But the overall objective of DataOps should sound familiar: DataOps involves processes and tools to ship high-quality data frequently—which requires a combination of data engineering, data quality, data security and data integration.

As with DevOps and MLOps, what the DataOps platform or DataOps engineer is doing is supporting the tools that help perform one of these activities and help build workflows. For example, a workflow may take data from a database, apply some transformation to it and then make it available for a business intelligence (BI) tool. That’s the kind of automation that is involved in DataOps.

As you might imagine, the skillset and the tools required for DataOps are quite different from the ones needed in MLOps and DevOps—so expecting a DevOps engineer to also be an expert in DataOps seems a bit unrealistic. While MLOps requires a much tighter integration with data than DevOps historically has required, MLOps is not the same thing as DataOps. More so than the other pillars that support intelligent applications, DataOps tends to be quite separate and distinct.

Conclusion

From perception systems to enterprise-scale fintech software, every intelligent application depends on three distinct disciplines: DevOps, MLOps and DataOps. And therein lies the complexity of developing intelligent products. Each of these fields is distinct, dealing with a different set of questions and objectives within the ML life cycle and requiring different kinds of people and tools. However, they are all fundamentally united by a common goal: Optimizing quality and speed of iteration of the ML life cycle. The tools, practices and organizations that will rise to the top are the ones that will enable more seamless collaboration between different ML teams, helping them move through the ML life cycle quickly and efficiently.

March 10, 2022
CircleCI Acquires Ponicode to Gain AI Testing Tool

CircleCI today revealed it has acquired Ponicode to gain control over a unit testing platform infused with artificial intelligence (AI) that makes it simpler to review application code prior to uploading it into a build. Financial terms of the deal were not disclosed.

Jean-Philippe (JP) Leblanc, senior vice president of engineering at CircleCI, said the goal is to integrate Ponicode’s testing technology within CircleCI’s continuous integration/continuous delivery (CI/CD) platform. That approach will make it possible to apply algorithms to individual developers’ code as well as to code aggregated from multiple developers within a build as it is continuously updated across a DevOps workflow, he added.

Ponicode was initially launched in June 2020 as a JavaScript unit testing extension for Microsoft VS Code. Since then, the company has started to support TypeScript, Java and Python, including complex functions such as variable mocking and infer suggestions of complex structures for nested objects.

The issue that DevOps teams frequently encounter is that even when individual developers test their code prior to uploading into a build, integrating different developers’ code can still result in an application failure. The Ponicode AI testing tools will give both developers and IT operations teams more confidence in the quality of the code being employed to drive applications, noted Leblanc.

Although not many developers want to admit it, Leblanc noted there is still a lot of sloppy code finding its way into applications.

In addition, Leblanc said the Ponicode acquisition will help the code review process become more efficient. Instead of requiring another developer or dedicated tester to review code, he said most issues will be surfaced by the AI testing tool that provides the equivalent of a built-in peer review. As a result, AI testing tools will improve the overall quality of the code being used to drive applications, added Leblanc. Developers will also be able to spend more time on the business logic that drives their application than on code reviews.

The goal, however, is not to eliminate the need for dedicated testing teams as much as it is to augment them and the developers they work with, said Leblanc.

It’s not clear to what degree responsibility for testing code is shifting left toward developers. However, many developers would prefer to have issues surfaced via an AI tool so they could address issues on their own rather than having them discovered by someone else. In fact, there are already more than 20,000 users of the Ponicode AI tool that plugs directly into developers’ integrated development environment (IDE), said Leblanc.

In general, there’s never been a greater focus on developer productivity. Organizations are attempting to simultaneously build and deploy more applications than ever—thanks mainly to digital business transformation initiatives launched in the wake of the COVID-19 pandemic. The challenge they face is recruiting and retaining developers. As a result, organizations are looking for ways to increase developer efficiency by eliminating as many manual processes as possible.

March 9, 2022
DevOps and Containers

“Works on my machine!”

We’ve all had that co-worker. I have had one at pretty much every company I’ve worked for. At several jobs, it devolved into a running joke.

There is a belief that containers alleviate this issue. And they may—or they may simply mask the issue. The choice is up to IT.

Inevitably, something that works on one machine and not another can be traced back to on-the-fly configuration changes. If “we use containers for DevOps” means that developers have full control of the container environment, then it must also mean that any configuration changes be codified into a documented container image that can be spun up repeatedly and even recreated in a Dockerfile if needed.

If, instead, it means that devs have a playground in containers and, once they get it going, they can chuck it into production—even if you don’t say it that bluntly—then you are making things worse with containers, not better. At least in the days of “works on my machine,” the issues had to be resolved because the only time you heard that phrase was if something didn’t work on the machines it needed to be deployed to!

As a developer, it is tempting in both container and virtual environments to upgrade a package or tweak a setting without documenting it. But a clean DevOps environment needs to be able to build the product from Dockerfiles, not from a pre-existing image. Yes, you can just clone the existing image, but then there is no documentation of what has actually been changed and it takes a lot more work for those following you and debugging future problems.

So take the time; keep an up-to-date Dockerfile (or whatever equivalent script is used to build your containers). It is not that significant an investment to stop for a minute, open a file and type a few lines. And it pays off in spades if, in the future, someone is trying to figure out what the heck is going on in there. Consider it self-documenting configuration. I’m not a fan of “self-documenting code,” but for config, it is pretty clear if you go, “Oh, we needed version 10.2, not version 10.1; let me update the init script.”

There are a fair number of shops out there that modify things running in production, and the world hasn’t ended yet—though that may well be how it happens. So, a good practice that will help those trying to follow behind you is clearly not a necessity. But each of us has gone back after a year and said, “Why did we do that this way?” which was (or wasn’t) then answered with, “Oh, here is exactly how the environment was configured.” But it might help answer the ‘why.’

Your apps are powering the world—or your specific apps are powering your little piece of it. And you’re kicking it just keeping them running. Now, go make them better! Consolidate changes, manage configuration through Dockerfiles, Ansible, init-scripts, whatever combination you use … And keep rocking.

March 9, 2022
7 Steps to Unleashing Your Citizen Developers
As digital transformation accelerates, organizations are searching for ways to enable all their employees—not just IT, development or DevOps teams—to design, build, iterate and launch new processes and applications as per their requirements. This democratizing approach is called citizen development—where business users are empowered to create their own processes and apps with only minimal supervision from IT, ultimately relieving them from IT backlogs.

How to Get Started with Citizen Development

Running a citizen development program doesn’t mean relegating IT to the sidelines. Citizen developers can often be prone to mistakes due to their lack of programming background. Limited skills may also result in creating a faulty app or unknowingly developing one that resembles existing software that serves the same purpose.

Thus, citizen development calls for a new relational approach that’s founded on transparency, trust and dialogue between IT specialists and non-IT employees.

As a business leader, you’re in the best position to initiate such a program. Here are the steps you can take to get you started:

1. Identify citizen development potential

You can issue surveys across departments or meet with division heads to understand who is using forms of shadow IT or already using citizen development tools, what they’re using these for and the number of users of these apps. Your findings can help you assess which departments have the most citizen developer candidates.

Also, determine your company’s backlog of IT requests and current IT pain points. Knowing the pent-up demand will give you an idea of what issues citizen developers can seek to resolve.

2. Set clear goals

Communicate what citizen development aims to accomplish for your organization. Identify the apps you intend to create, the mode of deployment, the role of citizen developers and which departments will benefit.

3. Get support from IT and fellow business leaders

Find partners in the IT team and among other managers who can help champion your vision for citizen development.

First, approach the potential managers who will be collaborating with you in this cause. Getting their support early can aid you in establishing a more well-rounded vision and avoiding any conflicts down the road. By helping them understand how it will actually boost their department’s workflows instead of delaying internal tasks, you’d be able to muster credibility for your proposal.

Meanwhile, assure your IT team that there’ll be a clear delineation of responsibilities between citizen developers and IT personnel. Employees will undergo self-directed and group training before being allowed to access a development environment. The software development life cycle will also be documented to make citizen developers aware of the process and necessary requirements for submitting their ideas. Moreover, IT developers will still be in charge of providing documentation, evaluating ideas and offering technical guidance with regular check-ins.

4. Shortlist low-code/no-code platforms according to your business needs

It would be best to look for low-code platform providers, schedule demos and invite IT and business unit leaders during dedicated sessions. They can compare feature sets and appraise learning curves with you.

5. Lay down a governance plan

A governance plan ensures that data security best practices are in place and that IT assistance is well-defined in your citizen development program. Such a plan should cover:
- The evaluation process for admitting projects into the citizen developer backlog or IT backlog
- Standard compliance and security requirements for any project accepted for citizen development
- Standard workflow protocols including testing, validation, audit and integration
- What instances will require IT involvement
6. Get senior management buy-in

You’ll need to communicate your intentions with your senior executives and prepare to formally present your citizen development plan.
- Establish the rationale behind the plan. Compare internal metrics with industry stats showing the current need for citizen developers. Cite success stories or case studies.
- Share internal figures pointing to the current IT backlog as well as results of surveys and discussions with employees and fellow managers.
- Calculate and show your company’s projected one- to five-year ROI for using low-code/no-code platforms for citizen development.
- Introduce your proposed governance plan and pilot program.
7. Start training

The citizen developers should be given time to learn the selected low-code/no-code platform. You can later pick a use case to pilot the tool. Identify your expectations and criteria to measure the success of the project.
March 8, 2022
Guide to Privacy Management for Developers
Privacy has taken on an unprecedented level of importance in 2022, primarily online privacy. There are multiple reasons behind this increase. The primary one is that users online are now more educated, informed and concerned than ever before about the collection of their personal data and, perhaps more importantly, how the website collecting this data manages and uses it.

Privacy management refers to the practices, tools and strategies that an organization develops behind the scenes to ensure that any and all data collected is managed in a way that is fully compliant with data regulations.

Like every other division within an organization, the dev and DevOps teams play a vital role in successfully implementing and executing privacy management solutions. But how can the dev and DevOps teams contribute in this regard? Where should they begin? What practices to adopt?

Be Clear About Your Privacy Policy

This has less to do with the organization’s practices and more to do with the overall philosophy about privacy. There’s no point in beating around the bush regarding data collection and users’ privacy since the better educated and informed your users, the higher their chances of giving you the appropriate data collection permissions.

You should be straightforward and let your users know why you need to collect their data. While this topic will undoubtedly be covered in the website’s privacy policy, it should also be reflected in the user’s browsing experience while on the site.

This can be done by ensuring there’s an easy-to-find and quickly accessible link to the site’s privacy policy across all web pages on the website.

Collect Only the Most Essential Data

This may seem like a given in 2022, considering how unyielding and austere most data protection regulations are. However, there are still organizations that are in the middle of transforming their data collection practices. That means that even though the legislation they must comply with requires minimal data collection, in actuality, their practices paint another picture.

This is not necessarily a deliberate or malicious practice. Most legislation, even those that are quite clear in stating that only the most essential data required for a website to function properly may be collected, gives organizations leeway regarding when they must adhere to these laws. The CPRA is perhaps the most vivid example of this.

While the CPRA was passed in 2020, it will not go into effect until January 2023. Most organizations are expected to ensure their data collection practices are in line with the law when it goes into effect. There’s no point in delaying the inevitable. If your organization hasn’t begun transforming and altering its data collection practices, it is high time to start.

Have a Data Transfer Mechanism and Strategy in Place

This is arguably the most sensitive part of any organization’s privacy management infrastructure. This is down to the fact that while an organization may have to comply with a data protection regulation in one country to process and collect data on its residents, it may find itself having to balance out its practices to be able to transfer this data to another jurisdiction.

Moreover, nearly every data protection regulation has a stringent set of requirements that an organization must fulfill before it can transfer the data out of the jurisdiction in the first place.

Naturally, this can all become incredibly messy and escalate into a crisis unless you have a proper data transfer mechanism and strategy in place that takes into account every possible step that may hinder your compliance efforts.

Ultimately, the buck stops with the dev team and DevOps team, in this case, to ensure that whatever mechanism the organization ends up adopting is fully capable of transferring data securely across jurisdictions without leading to a breach of any regulatory statutes an organization is required to follow.

Ensure Accountability

Some would argue that the entire philosophy of privacy management is built upon accountability. While various data protection regulations globally are meant to ensure all businesses follow a certain set of practices that reduce any chances of data breaches, true accountability comes from within.

The most practical method of ensuring such accountability is by maintaining a regular and up-to-date record of processing activities (RoPA). Again, this is something that most data protection regulations will require businesses to maintain anyway, with processing activities, data flows and categories of data subjects the most common items that need to be covered.

Similarly, make sure any third parties or vendors you work with have the relevant practices in place before going forward with any sort of data sharing, even if you have user consent to do so.
Remember, accountability means holding yourself and those you work with to the highest standards.

The most effective way to do this is to automate the process of record keeping. Owing to both the sheer volume of data that may become involved and the risks associated with human error in record keeping at scale, the best way forward is to opt for a data-centric automated approach.

Conduct Regular Assessments

Depending on which laws your organization must adhere to, regular assessments, known as privacy impact assessments (PIA), could be legally required. Most organizations design and implement their own PIA depending on their current practices and data collection methodologies.

However, there are some fundamentals that each PIA is supposed to follow, such as the following:

The what, why, when and how of all data being collected

Will the data be shared or sold to any third parties?

What measures are in place to ensure the data is stored correctly once collected?

The purpose of any PIA is to help you evaluate just how at-risk your organization is based on its current data collection practices. These evaluations can help you identify gaps and flaws in your current practices while also highlighting areas for improvement.

On the off chance that you do discover discrepancies, the best option going forward is to contact the organization’s internal data protection officer (DPO) and develop a roadmap for eliminating those discrepancies before they cause any real damage.
March 4, 2022
Secure Software Summit Series: Focus on Preventative Readiness
The connected world economy and the COVID-19 pandemic forced companies to accelerate digital transformation. Sophisticated cybercriminals have seized this forced acceleration to lay the groundwork for cyberwarfare. In reaction to recent attacks ranging from the SolarWinds breach to the recent Log4Shell exploits, many companies have quickly isolated and patched their systems. However, these reactive fixes do not work all the time; nor does the watch-and-wait approach. We must focus on re-engineering our organizational operations and culture to build and maintain preventative readiness. Companies and infrastructures need to be more resilient and secure from the start by building secure coding practices into the development process.

Secure Software Summit

At the beginning of 2022, ShiftLeft hosted the Secure Software Summit to provide industry experts and practitioners in the software development world a platform to discuss the latest methods and breakthroughs in secure coding and development practices—securing code earlier and better has become a discipline unto itself!

Some of the main takeaways from the event were:

SBOMs are in Your Future

In the very near future, organizations will need to better account for all the software and components of their applications, most likely via a software bill of materials (SBOM). The U.S. government has mandated barebones SBOMs, and we will soon see private industry start to mandate them, too, as part of procurement processes and auditing. This will enforce greater transparency and automate discovery of all dependencies and components in a way that, until now, was not common. Software composition analysis (SCA) will make this process easier and will become a standard part of the build process and the application development life cycle.

Securing Open Source is Critical

With Log4Shell and other open source software (OSS) supply chain attacks, application security teams must learn how to more intelligently update and secure the most critical OSS components and infrastructure. The average AppSec team needs to sift through massive piles of vulnerabilities and suggested security fixes — far more than they can possibly fix. We have seen record numbers of new vulnerability disclosures in each of the past four years. Proper prioritization based on whether a vulnerability can significantly impact an organization’s own applications and infrastructure is now essential amidst the blizzard of OSS dependencies that make up the modern application.

Digital Threats Impact the Real World

For many organizations in non-tech verticals such as health care that consume a lot of software, application security is at a crisis point—software vulnerabilities can literally put lives and our economy at risk. Researchers have correlated increases in mortality with hospitals running at higher levels of stress and capacity. When ransomware or other attacks impact health care institutions, the effect is the same as a massive pandemic flooding the ER: Doctors can’t use systems or equipment, care is rationed, patients are turned away and everything becomes more time-consuming. The net result is more deaths. Securing these systems against attacks becomes a matter of life or death—literally.

Culture Change Must Come First

Organizations will deploy new security architectures such as zero-trust, but these attempts will only be successful if AppSec and development teams change the culture around security. Organizations must recognize that the new normal is a state of constant renewal of trust. This will be challenging; constant renewal of trust requires entirely new infrastructure and a new mindset that can be hard on humans. It means implementing multifactor authentication in many more places and removing conveniences like administrative accounts that have blanket access to systems; it requires implementing least privilege practices. Software development will need to bake this constant renewal of trust into workflows and tooling to make it the new normal.

Shift From Reactive to Proactive

AppSec and development teams must shift from reactive approaches that tend to mobilize most resources during a breach or an incident and emphasize more proactive approaches such as better software security analysis and security chaos engineering. Knowing the unknown unknowns before they become a problem is key here. Netflix, which pioneered chaos engineering, recognized that stressing systems frequently and constantly to see how they behave under adverse conditions often yielded surprising insights that could improve security (and resilience, more broadly). As mentioned above, creating better ways to prioritize vulnerabilities and focus on the ones that are actually attackable shifts the task from a hopeless burndown to a targeted and proactive tactical exercise that is manageable.

Stay tuned for more articles to follow written by the following keynote speakers from the event:

Aaron Rinehart, Verica – Security Chaos Engineering

Dan Lorenc, Chainguard – The State of OSS Supply Chain Security

Steve Springett, OWASP – Behold the SBOM

Shinesa Cambric, Microsoft – Importance of Securing Software with a Zero Trust Mindset

Malcolm Harkins (Epiphany Systems), Rob Lundy (ShiftLeft) and Bryan Smith (RiskLens) – Reachability and Attackability

Abhishek Arya, Google – Measuring and Mitigating Risks in Open Source Software
March 4, 2022
Pulumi Adds Business Critical Edition to Infrastructure Management Platform

Pulumi today added a Business Critical edition of its Cloud Engineering Platform that provides large enterprises with additional security and compliance features, premium 24×7 support, training, professional services and a self-hosting option.

In addition, the company announced that Pulumi Enterprise and Business Critical editions are now available via the online marketplace run by Amazon Web Services (AWS), with future availability on other marketplaces planned.

The Cloud Engineering Platform from Pulumi enables DevOps teams to use Pulumi Packages to create reusable components for automating IT infrastructure provisioning. Those can be embedded within workflows and applications using an application programming interface (API) that Pulumi has exposed. IT teams can define a Pulumi Package in the programing language of their choice.

Aaron Kao, vice president of marketing for Pulumi, said the Cloud Engineering Platform from Pulumi provides an alternative to managing infrastructure-as-code (IaC) that can be centrally managed more easily than open source tools like Terraform.

Pulumi reported that adoption has accelerated across enterprises around the world with more than one million downloads per month. The company claimed it has seen 350% year-over-year growth of its enterprise customers, such as Mercedes-Benz, in the last 12 months.

IT organizations in general are looking to bring some order to chaotic provisioning processes to avoid misconfigurations that often result in, for example, a developer leaving a port open; that open port leaves a vulnerability through which data can be exfiltrated.

As organizations focus more on software supply chains in the wake of recent high-profile breaches, it’s only a matter of time before more questions arise about how cloud infrastructure is being provisioned. Much of the concerns organizations already have about cloud security don’t stem from the platforms themselves. Rather, it’s the processes employed to provision infrastructure under a shared cloud security responsibility model that results in so many vulnerabilities. Developers often assume the cloud service provider is securing configurations, only to discover later that it was their own responsibility to validate those configurations. Security teams, meanwhile, can’t keep pace with the rate at which cloud infrastructure resources are being provisioned.

Centralizing infrastructure management is especially important as the number of cloud platforms IT organizations manage continues to expand and the rate at which applications are built and deployed shows no sign of slowing, noted Kao.

It’s not clear whether development or IT operations teams will ultimately wind up managing the provisioning of infrastructure. Pulumi is making a case for a platform that enables those teams to more closely collaborate within the context of a set of policies and DevSecOps best practices that the IT organization defines.

It may be a while before the bulk of enterprise IT organizations are able to exercise the political will to regain control over IaC provisioning. However, in the absence of guardrails that allow IT organizations to make sure infrastructure is properly configured, it’s only a matter of time before tougher questions are asked about how software supply chains are managed.

March 3, 2022