devopsy.kinsta.cloud

Author: Don Macvittie

  • Let Me Reiterate – Don’t Rush to Iterate

    Let Me Reiterate – Don’t Rush to Iterate

    We in the DevOps world spend an inordinate amount of time talking about tools and roles—and there are always new tools and modifications of roles to talk about.

    Do you know what we don’t discuss as an industry? The day-to-day grind of being in DevOps. Oh, you can go to forums like Reddit and have those discussions with other practitioners, but pundits don’t discuss what it’s like to actually do the work. I secretly suspect this is because most of us pundits no longer develop code in general, let alone have a working DevOps environment. I certainly don’t code as much as I used to, and I develop more than many of my peers in punditry. For the record, we do have a working DevOps environment (two, but one almost never gets spun up) at my company, but I’ll be nice and won’t get sidetracked by talking about it here.

    We’ve talked about it tangentially, but I wanted to be direct with you all. The vast majority of your organizations do not need to iterate non-stop. And the mentality that you cannot iterate too much is simply false. While the guard gates and German Shepherds that protected production from rogue developers in the past were overreactions, there should be a happy medium. Every time change is introduced in production, there is some amount of risk. And we have a ton of tools to limit that risk these days—feature flags to turn new functionality on/off, auto-run testing before the move to production, etc.—but there is still measurable risk. And “we can just roll it back” only works in small, unsegmented projects. Once you get into nested dependencies (microservices are a great example), then versioning starts to make rollbacks an issue. Knowing the interconnected relationships between what is being changed is a big deal. So it is not as simple as the ::shrug:: “Just rebuild and deploy without your changes,” crowd would have you believe.

    And to a great extent, that is why this pundit doesn’t come out and blather about iteration speeds—the decision to iterate once every six months or every time Bob checks in code is very much an organizational/application one. How fast can the organization handle a full iteration, and how often does the application require it? The answer is rarely the insane number that vendors like to throw out to show you how great they are. There are a whole lot of organization/application combinations whose rate of change is slow enough that they could honestly schedule full-on iterations and plan updates around vulnerability patches in the underlying composite pieces. The majority only need to iterate over months. Very (and I stress very) few need to iterate even daily, let alone more than a hundred times a day. And they are indeed special snowflakes with super-tweaked environments.

    It is kind of stunning to me that a portion of the rise of Agile and DevOps was to free up IT time because we were overloaded. And then once that was done, we decided to crank up the rate of change so that IT was … overloaded. A release takes DevOps time, DevOps time and security time. It takes resources to build, test and deploy. Don’t overdo it.

    Build when you need to. Deploy when it is a benefit to customers. Keep rocking it. We’re out here using your apps, or your apps are grinding behind the scenes, keeping the business running. Either way, you know better than anyone what your app and your org need. Don’t follow the “10 billion deploys a day!” crowd; push for what works. And you are the SME in that department.

  • There are Few Enough Silver Bullets

    There are Few Enough Silver Bullets

    I was working through this week’s blog this morning, and it was laser-focused on a narrow topic. I had examples of why too much of a good thing is bad, how absolutism about methodology is hurting the majority of organizations out there, and how to get past this issue to keep improving what IT does for the organization.

    And I was nearly done when I decided that there are far too many areas of IT that suffer from absolutism, so I’d offer general symptoms and steps that work to get out of any of them.

    What do I mean by ‘absolutism’? Well, it used to be—and, in a couple of areas, still is—true that people would say, “We are an X shop.” And mean it. If you were a Cisco shop in the 1990s or 2000s, that is all you bought. Competitors were not allowed; nor was consideration of competitors. This applies to methodologies as well as product categories. In fact, today it applies to various methodologies more than products.

    And it’s bad for the organization, no matter where it comes from. While with vendors, it streamlines purchasing and offers the (in)famous “single throat to choke”, it also causes inefficiencies in costs (from your perspective, they are a monopoly, and some large vendors gained infamy by trying to take advantage of that fact), and causes people to do things in the least efficient way because that’s what the chosen methodology/solution requires.

    Sometimes, we manage to do the dance and avoid “One True Way”—take the move to cloud and continuation to multi-cloud, for example. While cloud vendors do not offer customers much leeway in pricing or priority (we customers are all cattle, not kittens), multi-cloud still offers us the opportunity to use the cheapest or best-suited cloud vendor without much drama.

    Many times, we are not so effective at avoiding the idea of a silver bullet. Take Agile. If there was a One True Ring of this decade in IT, I’d want it to be containers, but it would actually be Agile. Most IT departments zealously guard that Agile is the One True Way. Early-stage new product development is astoundingly well suited to Agile, and we needed it—if just for that part. Late-stage product maintenance, where changes are not feature-laden monuments to systems complexity, are also really well-suited to Agile and we should be happy to have it. In between? Large updates that can span data centers—or even continents—with a geographically dispersed workforce and hundreds (or more) of hours of development to get one sub-feature completed? Not really a great fit for Agile, and while many of us have said that for years, here is hoping things are changing. As I’ve said before, as maligned as waterfall was, it did the job for decades and handles large complex projects well. Maybe we need a replacement more in line with the times; one that incorporates what we’ve learned from Agile. I’d love that, actually. But what we don’t need is “We’re an Agile shop.” It is less useful than when it was said about products (at least if you only chose a single product, you got single sourcing and streamlined purchasing. With methodologies, you don’t even get that).

    Note: Agile is an example, not the point of the post. Avoid “One True Way” across your organization. Root it out and examine it. Sometimes, a single solution with a single specialized skillset is the perfect answer—at least for now. Far too often, “We are an X shop” is someone’s preference codified into corporate policy.

    To get past One True Way, you have to be there showing its weaknesses to management. There is some skill overlap when allowing multiple approaches or products, but if management starts prattling about that, simply point out the number of development and/or CI/CD environments the org is currently supporting. To show the overhead, track hours spent. Staff shortages have been endemic to IT for years. Make certain you know how much time is spent in overhead for the product or process, and try to map that to what could have been achieved with that time. It’s not perfect, but it will be illustrative. And don’t stop. Do your work, but point out every time that One True Way makes the job harder or more expensive.

    You are nailing it. Don’t let things like Agile keep you from churning out great apps for the company. I’ve been on teams where the time spent in process overhead was dragging down the ability to deliver quality. Fight that. Keep kicking it, and use the best tools/processes for the job.

  • The APIs You Really Don’t Know About

    The APIs You Really Don’t Know About

    A few years ago, we were rightly warned about the amount of exposure our APIs created. A massive attack surface that often used “security by obscurity” as its primary method of protection. We’ve come a long way since then, building secrets, tokens, RBAC and even more into our API interfaces.

    We’re still behind in getting comprehensive lists of APIs, but this bit is getting better as time moves on. Increasingly, both API management and DevSecOps markets are helping to catalog new APIs, and both the API management and application and API protection markets are helping to protect APIs that are unknown by tracking calls moving through the network. By using proxies, it is relatively easy to capture calls to APIs and report the list of APIs (and sometimes much more; about parameters and data transport, for example) to security or operations staff.

    In summary. the API management and security market has been doing great work, searching out the various APIs that are active in our systems, and cataloging new APIs as they are created. This gives us a comfortable and complete look at our current API environment and how it is protected. Most of these tools help protect what isn’t currently well protected.

    If only that really were all of the APIs in our networks. Unfortunately, that’s not the case. Because the ones not in this “complete list” can be the most insidious. As always, it is what you don’t know that poses the biggest risk.

    You see, there are APIs that are not currently maintained and are not currently actively accessed. Say you have an application that you installed from a third party—open source or purchased, either one—and then stopped accessing. Well, it is still sitting out there. The APIs are available—not necessarily documented and not necessarily secured. For security staff, this is how nightmares begin.

    Historically, we could count on these interfaces to be private. Those days are long gone in the hybrid environment. They might be private, but the definition of “private” is much looser than it has historically been and if there is a route from the internet to the API, it’s not private, and for well-known applications, is a time-bomb.

    This is another reason to clear out old versions and/or redundant installations of things like web servers and databases. Don’t make excuses—just upgrade them to the most recent version or remove them entirely. You can do this by merging what they do with a newer/better-protected installation or by just stopping them and fixing the apps that this impacts. “Turn it off and see what breaks” is admittedly a risky step, but sometimes will prove necessary to lock down the environment. If you don’t know what is using it, I’d argue your security risks are larger than an unprotected API hanging about, but that’s a topic for another blog.

    Meanwhile, keep rocking it. There is so much in your purview that we have to discuss what you don’t know about in the domain you are the specialist in. That’s not a weakness in you, that’s a statement about how much crap is tossed on your plate while making the org more competitive. And you’re dealing with it. So smile, keep kicking and lock down the scary bits.

     

  • The Scanner We Really Need

    The Scanner We Really Need

    IT has scanners for everything. And by everything, I mean everything. We scan source code for vulnerabilities and data leaks. We scan apps for vulnerabilities. We scan the network for holes. We scan our cards for access … Okay, that last one doesn’t fit, but you get the idea.

    Know what we don’t scan for (and what I propose we start scanning for immediately)? Secrets. Oh, there are apps that include finding secrets as part of their feature set—but only a part—and they only scan for secrets within their domain. What we really need is something all-encompassing. Secrets have a way of turning up everywhere—Git, flat files, databases, source code, email … If it can store text, your secrets are probably in there. The larger the organization, the more true this is.

    Way back in the day, I started working at a company that had mainframe admin credentials stored in a flat file on the network. I am not an InfoSec employee, but I can smell insecurity easily enough and I told them to knock it off.

    I am not mentioning the company by name because this is not indicative of their practices today, nor am I mentioning my position or the market, because anyone interested could then use my LinkedIn profile to figure out who it was.

    In my role there, I had the authority to tell them to knock it off, but they handed me a ready response: “Our network is secure, so we don’t have to worry about it. And we monitor the file … some …”

    The same type of mentality seems to permeate IT today. Security by obscurity is alive and well with regard to secrets, and yet we as an industry know (from hard-earned experience) that it is largely a myth.

    So, we need a tool that can access all the places that secrets might be hiding and ferret them out—I’m thinking like a simple UI that takes a secret and searches for it in all of the configured places—would be perfect. Well, almost perfect. Iteration 2.0 would report on what is accessing the secret in that location.

    Get secrets management. Several markets offer secrets management as part of a toolset, you might even own a product that can do it for you. Then, given the search tool and a good secrets management solution, you could search out all instances and replace access to them. Until iteration 2.0 comes out, you could replace them in a test environment and see what breaks—though we also have the hard-earned experience to know that this isn’t foolproof, so you’ll want to heavily document the change for that odd thing that breaks 20 months from now.

    This is not that difficult a product to design and build; finding where each secret is accessed from would be the hardest part. But that’s still doable with our current dev tools. One of you should build it and get rich.

    But meanwhile, as always, keep rocking it. Secrets stored in not-so-secret locations or not, you’re keeping the company running day in and day out. That makes you the stars of business. Keep up the good work.

  • Is Your Future in SaaS? Yes, Except …

    Is Your Future in SaaS? Yes, Except …

    The growth of SaaS—including IaaS—was phenomenal when it came and it has become somewhat pervasive. Today, there are SaaS tools in use at just about every business, large or small. From sales to marketing to customer management, there is a SaaS tool that does it affordably and well. For now. The same is true of cloud vendors. Cloud prices are kept low by two mechanisms—volume and profit. Volume; much like the theory that mass transit is cheaper, by putting many customers on a single server reduces cloud vendors’ operating expenses and thus reduces what the cloud vendor must charge to make a profit.

    But as costs rise and growth slows in the current environment, it is important that your IT department, as a customer, pays attention to the cost/benefit equation of all SaaS offerings. Some will remain beneficial because of the work they offload, even as prices increase for your organization. Others, you’ll see, will quickly outgrow the value they bring as costs rise and there is a third class that just isn’t worth it—maybe it never was and you haven’t bothered to pay attention.

    Look for those items. So that this is less vague, here’s an example: A company I am involved with has been paying for a SaaS service that simply emulates an on-site functionality. The organization could (and previously did) drop a couple of boxes in and achieve largely the same result. Recently, we looked more closely at items like this and found that, in this particular case, (though not in most SaaS cases the org is using) the cost of dropping two boxes in and letting them do the job was cheaper (assuming those boxes were upgraded/replaced every other year) than continuing with the SaaS solution at the current monthly price. So much cheaper, in fact, that a contractor could be hired to deal with any issues that came up with the physical boxes and the only increased work for IT would be maintenance updates to keep the system secure. If, instead of appliances, the solution consisted of two Windows or Linux boxes, even that maintenance cost would be minimized.

    Service will be the same or better—the devices are right there if a change is needed—and there will be one less link in the chain of tools/vendors for attackers (the physical solutions would be on a private subnet, SaaS cannot be). Assuming the solution is a quality product, there really is no downside here. And yet, for several years this company has used the SaaS solution. These are the low-hanging fruit that people will point at and call “retrenchment” or whatever. Ignore them. Do what’s best for your org—be it SaaS or local—and make that decision on a per-tool/per-project basis.

    And keep kicking it. You’re building apps and infrastructure that keep the company running. Don’t hesitate to take pride in what your team(s) have built and don’t hesitate to cut costs on things that don’t matter so you have more funds for things that do. And once again, thank you—from all the employees in your organization that don’t realize they should say thanks.

  • Update Those Ops Tools, Too

    Update Those Ops Tools, Too

    We’re all pretty well settled on the idea that the rate of change in IT has been on the increase over time. From the advent of VMs to Agile to DevOps to containers, the movement has been faster—and the same is true for internal development.

    I’m going to approach this topic from three perspectives instead of my usual two. Kind of like breaking the fourth wall in cinema. We’ll discuss this movement just a bit from the perspectives of my two preferred bits, DevOps and DevOps. But for this blog, we’ll also mention DevOps—the infrastructure, tools and processes that enable the other two.

    For DevOps, languages—both updates to those currently in use and the addition of new ones—bring with them a nearly automatic update to tools used. Favorite libraries/modules, IDEs, build tools—these are all looked at and updated more frequently today than at any point in history, by my estimation. For teams that do not change languages or libraries much, source code analysis (SCA) scanning is increasingly helping to take a closer look at all those included tools and filter them based upon impact (normally security impact, but other impacts on occasion, too—like project activity and stability).

    For DevOps, the toolchain is still new enough that evolution is causing regular change, and that change is bringing with it new tools and utilities to solve the problems of this existing infrastructure. In fact, I’ve long thought the DevOps part needed a bit of a cooldown on the change and new tools/utilities front, personally.

    And finally, DevOps has gone a bit sideways in this regard. Every person—whether you call them ops, admin or DevOps—responsible for troubleshooting machines and apps has a collection of tools. But the divergence of platforms has created a divergence of tools. It is possible to work without a dedicated set of tools—and, indeed, many DevOps engineers do. Others have a folder. Meanwhile, there is another dedicated set of DevOps engineers that have a PCMCIA or USB full of useful tools that is always with them. Some have both. Of course, what tools are included in all of this varies widely also. It is an interesting artifact of our growth in IT that developers tend to share or borrow the best libraries/modules/APIs across an organization, but DevOps is more independent. As long as DevOps team members are getting the job done, no one is all that worried about which tools they used to troubleshoot. They do tend to share if asked, but with little physical evidence of what tools they used, it doesn’t come up often.

    So, what am I getting at? Look for ways to enable DevOps tool sharing on an ongoing (or at least regular) basis. An internal social media channel dedicated to the vendor your teams use to communicate, brown bags, a maintained rating system “Why I think fdisk rocks” type of thing, etc. The more power there is at the fingertips of every DevOps member you have, the better. Given our history, building an “approved” list is likely a bad idea, but having that central communication location that security can also peruse to look for red flags is not a bad idea. Of course, they are likely too busy, but worst case, such conversations can help in forensic analysis later. Not being cynical, just living IT in the 21st century.

    And keep kicking it. More and better tools will help keep all those sweet apps and servers clipping along, so there is really only upside here. Give your teams the tools and revel in your considerable uptime.

  • Why We Still Need Specialists

    Why We Still Need Specialists

    A few years back, I wrote here that specialists—particularly infrastructure specialists—were not going anywhere.

    I think it is worth updating that prediction and reminding you all that specialists across the bulk of DevOps subdomains are still necessary—even if you have broken down their silos.

    Spend time in any of the variety of places that DevOps folks hang out and listen to/read what they actually say. When they express their sentiments as a real-time activity, the idea that we made one team responsible for most, if not all, of an application’s life cycle seems rather brutal.

    In most industries, we have increasing specialization as complexity increases. Even if it was allowed, most carpenters are not qualified to do plumbing or electrical work. Oh, most know the basics and could do it in a pinch, but they aren’t the expert that the plumber or electrician is. IT, for the last many years, has tried to do the opposite, with a decent rate of success. But practicality wins out over rigidity to make that success.

    We still have specialists. And you should ignore people that suggest they need to go away. The situation is already bad enough without having a person you can turn to for help with a harsh issue in this language, or on that piece of networking gear. While some of this—language specialists are the easy example—is merged into a DevOps team, some of them—network admins, for instance—only partially are. The networking within/between containers is often handled by the DevOps team (using one set of specialties), while the networking that allows all of the organization to run is still handled by operations. But I can’t think of an org I deal with regularly that doesn’t house these specializations somewhere.

    This is one of the things that has traditionally held back low-code/no-code solutions—they assume these specializations and will require specialists in whatever the underlying technologies are when things inevitably go wrong. The same is true (to a lesser extent) of DevOps, AI and automation. Someone has to know what is going on underneath—they must have specialized knowledge—in order to fix it when things go wrong.

    Remember, you are asking your DevOps teams to be both Jack of all trades and master of some. That is a recipe for failure, but DevOps is designed to withstand or overcome failure in short order, so I only mention this so you understand why new hires seem wild-eyed at times and old hands seem jaded—there is a lot going on that they’re mastering and remastering.

    So, stand up if you’re one of the “sailing against the wind” crowd. Be proud you’ve managed to thrive in an environment with a ton of specialist parts and make sure you know who to ask for help when something goes wrong and you end up out of your depth. Even if the answer to “Who can I ask for help?” ends up being “Learn it for yourself and then be prepared to help others,” you’ll rock it either way and the rest of us who have struggled through it feel your pain and respect your work. So, thanks—for those who’ve never experienced it, but rely upon your work.

  • The Great Market Convergence is Coming

    The Great Market Convergence is Coming

    When you look around tech markets—almost any tech market—you can see an obvious overlap. Tons of markets that are complementary and that take different approaches to solving the same problem, or markets that have grown into each other over time.

    This happens in highly active marketplaces. People have great ideas and implement them but someone else thinks a different approach is warranted, and the two don’t directly compete until they have to. There is competition within a market, and then there is competition of markets. I think we are about to see a massive increase in competition of IT and, specifically, DevOps markets. I admit to trying to write this without veering into topics I’m currently covering, so bear with me.

    Let’s take dynamic app protection as a topic. You can do that through your DevSecOps vendor, you can do that through your WAF vendor, you can ask around about AAP vendors if your WAF vendor isn’t one, you can do that through a variety of plug-ins and tools offered for web hosting software like Apache or NGINX … Indeed, IDP is actually just attempting to protect your apps dynamically. I’m sure I’ve missed several other markets that have rushed to fill the gap where live applications were getting nailed by hackers. I chose one market, but pick one in DevOps and start digging. You’ll find the same crazy amount of overlap.

    The thing is, we don’t need fifteen solutions to one problem; we need one or two—a handful at most. And combining the fact that most of these markets are way overdue for consolidation (considering the stresses the global economy is placing on trade) and I suspect we’re going to see a fair amount of that consolidation happen in a relatively short period of time.

    This matters to you for a couple reasons. First, if you think one approach to solving a problem is significantly better than the others currently available, your organization should be investing money there by paying for products and services. “More of us should have bought Betamax” is not a great look. Second, someone needs to keep an eye on how these changes impact the IT environment. If one of your DevOps tool’s vendors is in a merger, inevitably one of the merged organizations takes over and everyone does things their way. That’s not necessarily bad, but can be a scary time if, suddenly, you get an email about a change to a system that’s core to your department. Be aware of what’s going on out there and at least have thought about how you would respond if apps—or an entire market—disappear or are significantly changed.

    And, honestly, because it is the apps we are always talking about—DevOps, mostly—that are most likely to converge with a nearby market, it can seem huge. But remember that the core systems went through this long ago, and while they may go through another iteration of “merge this with that” in the future, it won’t be a huge volume like what the currently very active and young markets appear to be about to suffer.

    So don’t worry too much about which make/gradle/whatever variants you are using or what languages, which overlap incredibly, but tend toward niches. Focus on market spaces still growing and expanding. Know what might be at risk, and have awareness of whether you need to care today or you still have time before the market in question implodes or merges with nearby ones.

    And own it. We both know that when the time comes, whether you were prepared or not, you’ll rock a solution out—because that’s what you do, and there is no one behind IT to hand off to. So keep making your organization look great and just stay aware of the wider IT market trends so you’re not caught completely off-guard.

  • The Problem With Security

    The Problem With Security

    As an IT professional with decades of experience at every level of technology and organizations—from cell phone prototyping to banking enterprise architecture, from entry-level to CTO—I can state definitively that I have spent an inordinate amount of time dwelling on and dealing with security. And I know I’m not alone. This is a common theme. You could almost make a sitcom out of it. “What are your developers doing?” Uhhh … writing code? “That’s security!” I could go on, hitting on everything from users to cloud instances and you could fill in the “That’s security!” punchline every time.

    That’s a problem. But not in the way you might think. I spent many years thinking I was somewhat unique in that I always rose to the occasion and approached security issues head-on. Most of the organizations I’ve worked for didn’t have dedicated security (I’ve probably written about that before), so some of us rose to the occasion.  Nowhere near all of IT, but enough to feel like we were protected.

    I now realize that I’m not all that unique; that more of us are doing the “learn security to be secure” thing than are not. I see it in modern organizations all the time. And I think that the real problem is this: Most of these people, like me, did not see themselves as security staff—but they are. Most organizations don’t recognize them as security staff—but they are.

    We’ve long harped on cultivating security recruits from this pool, and I’m now going to suggest that you go even further. Make these people part of your planning. If you know that person X on the ReallyCoolApp team is ferreting out security stuff, ask them to just send an email to update InfoSec once a week. Don’t make it a huge burden, and don’t try to force them into a pure security role if they don’t show the aptitude and interest (you really don’t want unwilling security staff) but make use of their talents and drive. Certainly, if this person is doing a good job of making certain ReallyCoolApp is mostly locked down and DevSecOps tools are running against it for a secondary validation, then your limited InfoSec resources can be directed elsewhere.

    Replicate this throughout the organization, and “That’s Security!” becomes a benefit rather than a hassle to try to lock down. You already do some of this—since the automation of passwords, most identity management is handled by operations staff, with security merely providing policy and being available to ops if needed. I’m simply suggesting that you expand this type of approach to include every IT department (and some non-IT departments in distributed environments). Don’t recruit everyone to be InfoSec, but recruit them to do a little bit of InfoSec in their area of specialty.

    People have always said “Security is everyone’s problem,” which is true, but it’s far too vague to be useful. This is a workable intermediate. “Security is every team’s problem” and recruiting the people on each team most interested in InfoSec to formalize their involvement is a better approach.

    And keep rocking it. We need security everywhere, because ne’er-do-wells have made everywhere a part of the InfoSec battleground. So recruit people everywhere without moving them from their current roles/responsibilities. Don’t let the sweet systems you’ve nursed through the years get whacked by attackers when a little recruiting and nurturing will fill the gap.

  • DevSecOps Tools: Hot Air Ahead

    DevSecOps Tools: Hot Air Ahead

    I, like most of you, don’t like hardcore marketing that hinges its statements on “Well, that’s technically true…” I also am not a fan of talking heads that spew predictions about the future. Sure, they’re right sometimes; that’s because we have so many people pontificating that random distribution means some will be correct. I am bringing all this up to warn you that I (basically a high-tech talking head) am about to talk about tools, the future of tools markets (one in particular) and what I think should/will happen.

    Sometimes, talking about the future of a given tech is done to make a name for yourself. I don’t play that game. My goal is simply to say, ‘This is what I would like to see, and why I would like to see it.’

    Enough spewing—let’s talk about DevSecOps tools. I jotted down this topic a while back when I touched briefly on it, and my ideas firmed up while working on a recent project.

    Let’s start easy. If you are not using what we currently call DevSecOps tools in your DevOps toolchain, go get them set up. Go ahead, we’ll wait. It’s that much of a no-brainer that we’ll sit here while you choose, purchase and install your choice. Seriously. “Here is a tool that will make development more secure and make developers more productive.” Go install it now. Choose what functions you want to use and work them into your toolchain.

    But don’t get too married to your vendor. Because for the very same reasons I just told you to go install them, I will say I don’t think they should be a standalone market. Here is a toolset that plugs into the IDE on one end, and runs stand-alone, integrated with CI/CD on the other. It is DevOps in many ways. And while code scanning is inarguably a security function, the spirit of DevOps overall is “Who cares?” Using these tools shifts quite a bit of security functionality left and also warns about bad coding practices. Note I did not specifically say insecure coding practices, though those are covered. I said bad coding practices. The largest of these vendors will let you know things like, “Hey, you sent that variable to this function and then never used it. Are you sure?” or “This loop looks like it never exits. Are you sure?”

    It should be, and I predict will be, part of the DevOps process. In my dream world, the functionality would get split and some would end up in IDEs, while the rest would end up in testing tools or CI tools. But that’s not normally how markets get split up when there are established vendors. Even though you can feel the difference in the functionality (a bunch of them plug right into the IDE; the rest don’t), it won’t get split up because existing markets generally merge through acquisition. So we’ll have to see how things fall out, but I’m betting on CI/CD vendors or system-wide security vendors moving into this market. Indeed, companies with a SOC will likely find these vendors appealing because most of them also operate SOCs for the dynamic scanning part of the system.

    Still don’t have DevSecOps installed? Go now. Choose a vendor.

    Because I’m being so forceful about telling you to install one of these toolsets, I’ll state very clearly: At the time of this writing, I do not have any kind of relationship with any vendor in this space. I say this because I use the tools and strongly believe that the pain points they bring as a layer in development are very much made up for by the benefits they bring to the application.

    And keep rocking it. This will just make your systems more stable, and the merges (that I see as inevitable, but is actually only a possibility) you can worry about when they come along.