devopsy.kinsta.cloud

Tag: agile

Agile is no Excuse

Did you ever hop in a car and just start driving with no destination? I know someone who used to do that for relaxation, but while I do enjoy a good road trip, the destination is far more important for me than the journey. My Mom lives nine hours away, and I love to go visit her. I know the routes like the back of my hand and just get to enjoy the ride—precisely because I know where I’m going.

Most people wouldn’t sign up for a cruise that refused to tell them what stops were planned or even where the ship was going. But those same people are currently in a boat built by either IT or vendors and they have no clue where that boat is going. This is an issue with the software industry, not with the people in question. I recall a couple of memorable cases (not naming names here, but you no doubt were a victim of or heard of at least one of the examples I can think of off the top of my head) where a vendor suddenly announced they were changing everything, and customers would have to deal with it (moving platform, changing licensing, suddenly becoming a product in a different market …)

That’s crazy. Honestly. You could have a piece of software central to your DevOps operation suddenly change to be less useful or even unsuitable. A company you have a contract with. The advent of “commodity” virtual hardware and everything-as-a-service has made us lose sight of the fact that customers have a need for stability and are not in the least wrong to demand it.

And that brings us to today’s actual topic. More and more vendors respond to “What’s on your roadmap?” questions with, “We’re agile, so we are constantly improving.” That is a non-answer. I am a human, so I’m constantly improving, too. Weaning from a bottle at 18 or 24 months says nothing about the roadmap from today for the next 18 months. As an analyst, I generally start advising users that this stance is bad for them and they should demand any vendor they do business with have a plan that they can count on for at least the next 12 months. And that they should leave vendors that don’t have that, and not sign with ones that won’t if not already a customer. Agile means you are making constant changes. We didn’t ask how often you update; we need to know where you are steering your product. If you can’t answer that question, no one can, and the product is in jeopardy.

The problem is, because we, too, are agile, a lot of IT shops are doing the same thing to their customers. While the feedback loop is shorter and more direct, the fact is that most of you have surprised business users with some new thing. The fact that they often are thrilled to have it doesn’t change the fact that they should have known it was coming long before implementation. Agile doesn’t excuse bad communications, and DevOps is not short for ‘random change on a whim.’

So, demand your vendors offer you predictability – even in a fast-changing market – and offer predictability to your users. It only takes a second to update (automated or via email, Slack, whatever) customers that a change is in the works but not assigned yet. Or even just got assigned; just offer some warning. Be good to your users, and demand vendors be good to you. Agile, DevOps and SaaS do not require unannounced changes (good or bad), so stop acting like they are acceptable when notification systems are already set up.

In short: Stop saying, “We don’t know where we are going, but we’re Agile, so we are getting there super fast!” And stop letting vendors say it to you. You are knocking it out of the park every day. Systems run and people use them and all works as intended… Because of you. Now consider letting users know when changes are coming – not just the big ones, but the ones hidden in “We’re Agile!” Make your vendors do the same to give you peace of mind, too.

January 24, 2024
New Year, New ‘Tude

There are multiple types of debt in an organization. In IT alone, you can have technical, ops and (my favorite) attitude.

We work in a high-stress field with a lot of moving parts and an enterprise depending upon us to keep things running. Even if you are in the product development org at a software company, you literally make the product; people are more dependent on you doing it right most of the time and being super proactive when things go wrong.

All of this creates stress that we tend to either internalize or leave to find a new place to get our stress.

Internalizing makes for jaded IT folks. Or worse, cynical ones. Vacations are part of the salve to relieve that stress, and we just got a couple of weeks off. Or at least most of us did, some of you all are about to, and others will in February. But it is all the same.

To continue improving, we need to leave the baggage behind. “Blameless IT” improved how others judge devs and operators that make mistakes, but we’ve done little to improve when devs and operators see problems that they cannot fix and it festers.

When you return to work, take a deep breath, consider what you can do something about versus what you cannot. Then, take action on the things you can and ignore the things you cannot. Improvement is what matters; improving a specific broken process isn’t. Of course, it will eat at you if you pay a ton of attention to something you cannot change. I have always taught those working for me (and my kids, for that matter) to change what you can and not dwell on what you can’t—precisely because you can’t.

If the thing you can’t change is a show-stopper and makes your life miserable, then the thing you can change is your job. Start looking.

Between Agile, DevOps and new deployment methods, we have come a long way in technology, but we also have created a ton of work for ourselves. This stuff doesn’t implement itself. Focus on that work and on how you can make things better – for the org, for IT, for fellow developers or operators. And do that. Always improving and not dwelling will make life happier for you and generally more productive for your team.

I’m excited for a ton of things that 2024 is bringing, and a couple of things that aren’t necessarily ‘2024 new,’ but that I’m still figuring out. Let’s do new stuff with a smile, because we know we’re making things better/faster/more reliable. And implement that feature your users all want and your team hasn’t done yet, while you’re at it. Users are the reason we do this, in the end, be they internal or external.

We made it through 2023 with some great improvements—no doubt you did, too. Now, it’s off to 2024 to do more. Keep rolling out features, protecting the systems, deploying to new targets, etc. And forget about that stupid annoyance. (Until you can change it—then crush it like a bug). Meanwhile, thank you from all those that don’t realize they add to your stress every day.

January 10, 2024
Best of 2023: ‘Scrum == Cancer’ ¦ Plus: Linux 6.5 Ships

As we close out 2023, we at devopsy.kinsta.cloud wanted to highlight the most popular articles of the year. Following is the latest in our series of the Best of 2023.

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: Scrum sucks, sources say; and here comes the Linux 6.5 kernel. (more…)

December 29, 2023
The Trouble With SaaS (or, Nothing is a Silver Bullet)

It is intriguing to me that we have to have this conversation about SaaS and software updates yet again. There is supposed to be a balancing act between the desire of investors, efficiency for the org and the needs of the customer. Right now, that balance is (yet again) all out of whack.

I actually got to thinking about this doing work for my non-IT company. One day, I realized that between browser, OS and office solutions, we were updating and restarting something nearly every night. Then, we were forced to upgrade our accounting to a really great SaaS product. Considering that a product that has served both of my businesses so well for a decade will soon be replaced in our environments, apparently, it is excellent for investors’ mindset, not so much for customers. Oh, it’s easier to access, but it comes with a separate set of weaknesses that would cost my less profitable business a ton of money. Since I like to keep the solutions standardized between the companies (for the accountant, if nothing else), the SaaS product will have to go at both orgs. We reverted to their discontinued local install product until evaluations were done to replace it entirely.

The problem is that both SaaS and rapid iteration are great on paper, but like just about every good idea in IT, they are being treated like a panacea. Sure, recurring revenue from SaaS is great. But if you lose customers doing it, that may not work as well. The same is true with rapid iterations—once you get to consumers, updating even weekly is a bit of crazy-town. Most end customers look for a way to turn off updates as soon as they notice the pattern. Business users aren’t much better, we all have stories of systems or hardware that weren’t updated for years. Heck, I worked on teams that hadn’t updated their own systems to get them off of outdated OSes and hardware, let alone kept on top of vendor updates. This is part of the reason for the drive to SaaS – to force upgrades. But if frequent updates introduce errors for the customer, well, it’s a lousy reason.

Make your products good, and make certain you are serving the broadest piece of the market that makes sense. Of course, follow trends and make sure you are still doing what makes sense. But what makes sense is what serves the market and/or the organization’s bottom line. Everything else is input. Some will say, “In good SaaS, the user never knows if there is an issue.” Yeah, and I never wrote a bug. Seriously, don’t force things on customers; give them what they need, where they need it. In one (security) space I cover, my regular advice to vendors is, “Users need this one bit of functionality behind the firewall and stable. Give it to them, SaaS or not, or lose them.” But that sentiment is increasingly being applied outside security. Users want vendors and products to do for them, not to them.

In short, do what you like to see from your vendors. The convenience of a SaaS accessible from anywhere and free of capital expense is huge, but it isn’t always the deciding factor and, in many spaces, limits market appeal. You all know what is useful, and you know for a given toolset what is not. Apply that mentality to your own customers. And keep rocking it. Sooner or later, this deployment octopus we’ve created will come together, and we’ll have different problems to fix.

November 29, 2023
Improvement Cycles and AI

It’s that time of year when pundits start to crank out their predictions for the next twelve months! I’ve been asked to contribute to a private group (and occasionally, Techstrong Group asks me to contribute to their annual list), so I won’t thrill you with my predictions just yet; but I will discuss the cycles and trends that previous predictions have shown.

Back when I was testing physical servers, we thought of throughput bottlenecks in terms of where the problem was. The circle would go disk->memory-> CPU, and in the case of things like NAS, insert network in there somewhere, too. When one bottleneck was resolved, another would crop up. And users will always seem to be pushed to the next bottleneck.

We see similar cycles in DevOps. First, Agile made development faster, and that caused us issues throughout the rest of the process. Then, DevOps helped with the build and a little with the testing and deployment steps, but in the early days it was more standardization than speeding up. And since then, we have been in that cycle. We’re seeing GitOps speed up and automate deployment and upgrades—based upon the automation that came before—we’re seeing test and security tools feeding directly into the IDE to speed resolution, we’re seeing container automation cause “cloud-first development” (I hate that name; Kubernetes has cloud-like interfaces, but is not precisely cloud) to be fully automated, and thus faster.

And we’re looking at that cycle continuing. No doubt you will hear a lot of predictions that start with “AI …” For the most part, AI is a tool and/or technique. Listen for what it is improving because it is doing very little that’s actually new. (Delete list of things that sounded alarmingly like those predictions I said I wouldn’t make.)

All in all, we are still living in a very cool technological time. We can have a tool generate code snippets of the dull work for us so we can focus on the important bits. Some shy away from this use of “AI,” but honestly, we already use libraries to do the grunt work—I haven’t written to a screen buffer in forever—because we don’t have to. Same story—use the tools that make you productive. Some of the more obscure bits of Linux command lines are far better dealt with by asking an AI to give me examples than searching through tons of docs across several platforms. Never was much of a fan of man output for complex commands, this makes it easier. The nice bit is that bash and UNIX utilities don’t change much over time, so answers can be a bit dated and perfectly accurate. That’s not true for much of IT.

The environment has consistently gotten more complex, while the building blocks have gotten easier to use. This allows things to keep moving and changing while it offers us better ways to serve the organization’s needs. This does change at some point—infinite change is indeed a thing, but any technology does have its limits—but I honestly can’t see the point at which we are content with our IT tools and stop looking for more. Oh, most organizations go through those cycles—organizationally, once an infrastructure and process works correctly, it is likely to hang around until better is found—but the industry will keep changing.

And you’ll keep learning and changing. That’s one prediction I will make for next year. Teams and IT staff will grow and learn new things, because at its heart, that is what we do. We learn new things and keep the lights on. In good years, we offer sweet new tools and functionality to the company or our customers. But either way, we keep things online. Year after year. You all rock, so that’s an easy prediction.

November 1, 2023
Remember: Tools Fail, Too

Between agile development methodologies and DevOps, we have largely removed the stigma of incremental – or even architectural – failures in development, deployment and, more recently, security and operations. Even data management, with increased redundancy and recoverability, has moderated its crazy responses to failures.

This is all good news. Rather than focusing on blame, focusing on fixing the problem and stopping it from happening again are better uses of our time. I’ve pulled some really dumb stunts in my decades of IT (most recently, I trusted a hardware vendor that historically I had trouble with. Unsurprisingly, we are paying that price now. Replacement parts are arriving today–required because they still try to lock you in). So have each and every one of you. No matter how well-trained an individual is, on-the-job training is a fact of life in an industry where most technology innovations last about as long as a cappuccino and we’re asked to know a little bit about a lot of topics to complement our specialty. (I’ve been a dev, worked in ops, as an architect and in security … none of those jobs was doable without working knowledge of the others).

All of that is to say, “We’re admonishing each other less and fixing things more, and that’s good.” I don’t need to point out that there is a balance implied in that statement; most managers are well aware that occasionally a person’s skills/interests aren’t a great fit for the position, and changes have to be made.

But the point of this blog is to say, “We’re really good at acknowledging failure at the granular level, correcting, and making sure it doesn’t happen again. But only at the granular level.”

Yes, the person who championed a tool or system into the organization is going to feel the need to defend it, and we have to acknowledge that this is no different than the developer who made a bad architectural choice feeling the need to defend it. Some tools suck. Some implementations are not great for our use case (I know a group of smart people who can help you figure out which tools do; follow my LinkedIn) and some tools we’ve moved beyond their capabilities.

We make technology decisions for the organization almost every day. Some of them won’t work out in the short term – we’re not terrible about cleaning those up outside of the inimical “executive sponsorship” that sometimes saddles us with suboptimal solutions. But the ones that are kind of successful are the bad ones. We end up limping along when most staff know there are better solutions on the market or even new markets that solve the problems more elegantly.

Most organizations have some form of technology review process–many smaller orgs have that person who makes final decisions, and many larger ones have committees that look across product lines and technologies. Those reviews have only kicked in when something is obviously a hindrance to operations because we don’t have time to muck around with things not broken. And yet, that is not the Agile/DevOps way. We need to be aware of the friction points and smooth things out. I’ve written before about considering standardizing toolchains, and that’s one thing this could evaluate–number of tools versus duplicative effort and disparate training-but a look at any tool included in multiple issues is a good idea, as is “Prove to me this is the best solution”-type conversations.

Keep kicking it; accept that there are reasons that some suboptimal tools will exist, but remove those that provably have better/more efficient solutions for the organization’s needs. I once moved an entire massive data store across platforms because my initial scale-up approach slowly became less appealing than the competitor’s scale-out approach to the same problem. The people I saddled with doing the conversion gave me more grief than my fellow managers, but things worked better afterward. So be honest, but be willing to admit that one risk of the hundreds you take didn’t pan out. And keep the company rolling forward. Your work is critical.

October 18, 2023
3 Ways to Achieve Faster App Development Without Compromising Security

Bringing products to market quickly, efficiently and safely is key to brand success, and elite DevOps teams minimize the lead time for changes by quickly and efficiently moving new products and software updates from concept to deployment. DevOps teams often measure lead time in hours, not days, weeks or months, which underscores the centrality of speed in today’s hyper-competitive online environment. Customer experience and brand loyalty are constantly changing as new products and services come to market, and DevOps teams are under immense pressure to stay as agile and efficient as possible. Increased technology development velocity can lead to heightened security risks. As of early 2023, as many as nine out of 10 companies have detected security risks in their software supply chain. This is why companies cannot ignore the rising number of attacks targeting software development teams.

High-profile incidents at SolarWinds, NetBeans IDE, Kaseya and Codecov demonstrate the risks facing software development teams at every company.

These threats exploit the continuous integration and continuous delivery (CI/CD) process to sneak harmful software into authentic applications and install risky and harmful components whenever possible.

The risk of code injections makes safeguarding internal and external dependencies crucial. If not appropriately protected, compromised software pipelines can lead to data leaks, code tampering and system exploitations, putting the entire business at a heightened risk.

Simply put, DevOps teams must maximize development speed without compromising security. This is an undoubtedly tall order, but one that’s achievable with the right processes in place. Here are three strategies DevOps teams can implement immediately to reach this goal.

Streamline Privileged Access Management

Streamlining privileged access management is vital for enhancing cybersecurity in DevOps teams, particularly with the growing threats to software supply chains. This requires adopting stringent security practices, including temporary access permissions that can be granted and revoked as needed—a strategy ideal for managing temporary services in DevOps workflows.

This approach facilitates automatic management of access privileges, including revoking password permissions when team members leave the organization or project and thorough scrutiny of who has access to what.

At the same time, enforcing least privilege access, a principle that aims to minimize the attack surface by eliminating unnecessary permissions and adjusting overly broad ones, is also essential, reducing the chances of account hijacking or theft of static API keys.

Similarly, zero standing privileges are also essential, relying on just-in-time access management that ensures minimal active permissions at any given moment, enhancing security by reducing potential vulnerabilities.

Leverage AI Solutions for Security

The cybersecurity AI sector is soaring alongside escalating cybersecurity threats to DevOps teams.

Deloitte expects cybersecurity AI solutions to become a $19 billion market by 2025, as the technology’s “ability to adaptively learn and detect novel patterns can accelerate detection, containment and response, easing the burden on SOC analysts and allowing them to be more proactive.”

AI can help DevOps teams detect and prevent cybersecurity incidents by quickly identifying and monitoring applications at risk, ensuring greater resilience in their DevOps processes through CI/CD, applying analytics to streamline data challenges, and identifying potential hot spots before they escalate and present real risks.

AI can also help combat alert fatigue within security teams, reduce analyst workloads and cut down on false positives, saving valuable time. According to a 2022 IT industry study, 60% of respondents receive more than 500 cloud security alerts every day, and alert fatigue is “causing critical alerts to be missed at an alarming rate.”

By leveraging AI for cybersecurity, DevOps teams can enhance their defensive posture without diluting their team’s impact, allowing them to best balance speed and security in the app development process.

Enable Communication and Collaboration in DevOps Teams

In the realm of DevOps, success relies not only on implementing the right tools and technology but also on fostering an adaptive culture that encourages seamless communication and collaboration among team members.

Effective communication forms the bedrock of this cultural shift. By establishing clear lines of communication, development and operations teams can better understand each other’s challenges and perspectives. Open dialogues can foster mutual respect and create a shared understanding of common goals, thereby encouraging a collaborative problem-solving approach.

Meanwhile, fostering a collaborative culture is equally vital. When teams collaborate effectively, they can identify and resolve issues more quickly, improve the quality of the software, and accelerate delivery times.

Embracing Speed and Security in App Development

Achieving faster app development without compromising security is a complex yet achievable goal in today’s competitive environment.

By investing in streamlining privileged access management, leveraging AI and fostering a culture of effective communication and collaboration, DevOps teams can enhance both speed and security.

To be sure, in the face of escalating cyberthreats, speed and security are not mutually exclusive but, rather, two sides of the same coin. By implementing these strategies, DevOps teams can navigate this delicate balance, accelerating development timelines while ensuring robust security.

September 7, 2023
Agile Planning With Generative AI

Generative AI will eventually impact the entire DevOps life cycle from plan to operate. I started as a developer but have been a product manager for most of my career; for me, the ‘Holy Grail of DevOps’ would be one where product managers (PMs) and business analysts (BAs) were able to define a future state of a business process and press a button to deliver it without any developers, designers or testers involved.

This dream is not practical in the near term and is not really desirable in the long term, either. PMs and BAs are good at understanding the needs of users and translating them into features but aren’t interaction designers. AI may be able to generate code and tests, but the software architecture for both will still require a deep understanding of the system to structure the solution properly, especially in enterprise SaaS development. So my dream is to build a team where the BAs can define the changes and a small team of very talented architects and interaction designers can realize those changes in 10% of the time it takes today without requiring a large team to implement the details. This is similar to what has happened in manufacturing where robots and numerically controlled machines are able to do the heavy lifting with the help of operators.

Planning is Key

When generative AI is actually building the solution, proper planning will be the entire key to success. A well-documented, well-thought-out plan will enable the AI to finish most of the heavy lifting. So the majority of the focus for the dream team should be to get the plan right and to document it at just the right level of detail. Just like I was taught by my first Agile coach 20 years ago, when it comes to documentation, you need just enough just in time.

In enterprise SaaS platforms like Salesforce.com and ServiceNow, the business starts with a newly implemented system in some initial implementation and then incrementally customizes this software to better meet their needs over time. So, instead of thinking about building a system from scratch, we must think of digital transformation as the continuous improvement of an existing system over time. That means the AI must start with a good model of the

● Existing business processes,
● Metadata configuration of the system and
● Dependencies between the settings.

Development in the New World

What does this mean in practice? Let’s look at a day in the life of the dream team.

The BA will start by telling the AI what changes are desired at a high level. The AI will help refine the requirements by filling in missing details. This will happen through an iterative process of expanding, refining and summarizing until the requirements are clearly defined. Just as lint tools check source code today, the AI will examine the requirements to ensure the user stories are complete, with acceptance criteria well defined. During this process, the AI will do a detailed dependency and impact analysis to provide a heads-up to the BA when there are any unwanted side effects.

This refinement session will be more of a conversation between the BA and the AI than a one-sided writing session. After several iterations, a complete set of user stories will be created with all of the necessary details spelled out.

Once the requirements are complete, the BA will be joined by a user interaction designer and software architect.

The interaction designer will define the interaction spec through a combination of natural language description of the new processes and a functional prototype. Both of these elements will be created and refined through interactions with the generative AI. Prototypes will no longer be simple graphic artifacts to be coded by front-end engineers. The AI will generate a working prototype in the framework of your choice on demand through a combination of verbal requests and traditional point-and-click.

They will review the plan and begin designing the solution’s architecture which will result in a natural language software spec that documents the data model changes and high-level specifications for the classes that make up the solution. It is likely that the data model changes will be created in a dev environment on demand, with the ERD updated to reflect the new model.

Depending on the type of changes, the architect and interaction designer may collaborate and iterate on the specs until the “how” is well defined. When the design is ready, the dream team will meet to review the design and sign off on the approach.

Generate and Iterate

Once the plan is approved, it’s time for the AI to generate a first-pass solution. We hope and expect that generating the solution will be something that happens in minutes. In this scenario, the dream team will take a coffee break and then come back to the meeting room to review the working solution.

There is nothing like playing with the actual solution to remind you of the edge cases you forgot or to realize how tedious it is to actually use a new feature. But that’s okay because the team can quickly update the requirements to account for these changes and push the generate button again.

In fact, they can tinker to their heart’s content. But like all great artists, they must decide when it is good enough to ship.

In the near term, we will not be able to blindly rely on generative AI, so the architects will have to do code reviews, just as they do today with junior developers. Likewise, the AI may not understand all of the possible dependencies in a system. So there will be a transition period where the process is semi-automatic.

Eventually, the notion of a two-week sprint will seem anachronistic and a daily cycle of define and release to production will be commonplace. Members of the dream team will spend more time worrying about the high-level usability and effectiveness of their designs and less time struggling with actual implementation, which should make their jobs much more rewarding and the work product much better. I am looking forward to it.

August 3, 2023
Identify Needs First

In several projects of late, I have noted a trend in otherwise rockstar IT departments: They identify an area that they wish to implement or approve and then set out to address it. So, “We need a new CI tool,” spawns a project to choose and implement a new CI tool, for example.

But there are so many details that these projects are missing from the start that should have been put right into the charter/project kickoff documents.

Let’s start with, “What CI tools do we currently have in place?” This is the 2020s. How is it possible we are still starting these projects as if there was no solution in the virtual building already doing the job? We need to start from, “Here are the tools that can do this job that are currently running in our environment.” Only then should we move on to, “Here are other options to consider.” But I will humbly suggest that if there is a single tool that can solve your issues, it should be used–and if, of all of the tools running in the organization, none of them can solve all of your issues, then a new product should be chosen that can.

The same is true for things like alerting. When I am analyzing a given vendor’s solutions, I ask about how many places they can raise issues–it is important that a vendor asking you to purchase their product can report and alert to whereever the organization needs it to. So that could mean Jira or ServiceNow, Slack or email, centralized logging—all of the above and sometimes more (SIEM for security events, for example) need to be supported. But when a given organization is implementing? Choose a reporting method.

The most common is, “We do Slack, but we also do email. And, of course, we coordinate though issue management like Jira …” Stop. Seriously. This is not about, “Oh, they made it easy, so we just implemented every option.” This is about, “We need to keep track of conversations and resolutions.” If two people are discussing an issue over Slack while a separate team is discussing over email, you’re failing to communicate. Even if there is linkage to ServiceNow or Jira and that is where conversations should happen, we all know that final resolution—but not troubleshooting steps—is what ends up there. So offer one robust and widely available alerting mechanism and let people run with it.

That type of redundancy is all over IT. Organizations that would not implement per-team email solutions (not servers, solutions) will happily allow for per-team DevOps toolchains. Why? What, exactly, is different? The purpose of a mail server is to deliver mail. Choosing which mail vendor/service to run with is based upon how a given product does so and what additional services come with it. How is that different than, “The purpose of the DevOps toolchain is to deliver applications, and selection is based upon what vendor/product best serves the way our organization does so?” There isn’t a difference; we imagine one. We latch on to one feature that we must have to keep our current favorite, and the compromise is that the next team over can keep their tools, too, because they must have some other feature.

Evaluate what the organization as a whole needs, identify tricky bits like must-have features and determine if that really is a requirement. If it is, ask why it isn’t a requirement for every project not using that tool.

And keep moving those apps along! You are building and deploying more apps more securely than ever before. Continue to sanitize the build and delivery process, and continue to crank out apps that make the business hum. But don’t make it part of your job to support fifteen tools that all do the same job. Streamline and improve. And keep rocking it.

July 5, 2023
The Security Pipeline

Over the last few years, the ability to secure our applications has grown, and deep integration into the DevOps toolchain has, too. There are more tools doing more security checks protecting more of the infrastructure and source than there have ever been. The key is putting them to use intelligently.

We now have the ability to secure the image an app is based upon, the images that are derived from that original—complete with supporting software. We can get feeds to tell us which bits of our included open source components are insecure and how to protect them; we can scan the source, the assembled application, the APIs and the network. We can put runtime protections in place in front of web apps and in front of APIs. We can even track the long-tail attacks like slow data extraction that are becoming more common as security tools master more obvious attacks.

That is a great set of security capabilities. And automation puts every bit of it within reach. Your job is to pick the bits you need to increase the security posture of your environment and get them worked into your specific toolchain. This is not all that difficult, but nothing is free, so you will need at least some implementation time and some staff time to work through results. After all, no matter how automated, current solutions do end with a list of changes that need to be made to increase security. Some tools will put a runtime fix in place immediately, but honestly, that is a patch—it only stays in place until you can fix the underlying issue.

Integrating all of the great security tooling with each other is another aspect that will require some time. Some vendors cover a massive amount of the security testing needed across markets and technologies. These companies show us that even if an organization would rather use best-of-breed, there is a lot of benefit in increasing integrations. For an easy example, consider this: If the software bill of materials (SBOM) generated during the build steps shows that a given framework is included in an application, then active testing via dynamic or interactive application security testing can include extra tests specific to that library.

Integrations will take effort, but once they’re in place they will enhance application security. There is no perfectly secure application, but the tooling is available to make a given environment less of a target because it is too much work to attack. And that is what you should be shooting for.

I’ve said before that making security part and parcel of your DevOps practices is mandatory at this point, but that was in reference to the great DevSecOps toolsets currently out there. I’m suggesting now that we include it all–from design to GitOps runtime drift management. Because we can, and the result is reduced risk to the organization.

And keep rocking it. Honestly, you’re maintaining something worth protecting–that alone means you are successful, even if you aren’t aware of every issue that crops up. Issues are why you’re there, and the systems keep running because you are.

June 21, 2023