devopsy.kinsta.cloud

Tag: SCA

  • The IT-DevOps Life Cycle is Like a Pyramid That Keeps Growing

    The IT-DevOps Life Cycle is Like a Pyramid That Keeps Growing

    Don’t let anyone tell you how much easier IT life is these days. It is, in many ways, more fun and productive … but it is not easier. In fact, we’re doing more with less, cubed, at this point. My point is—think of the life cycle as a pyramid. The base is the build++ chain, from VCS to public-facing active protection; the height is the new technologies and systems being bolted on daily—like SaaS tools someone in accounting just signed up for or the new architectures a dev team in a subsidiary just decided to adopt (but which will eventually have to be maintained by IT). And the depth is the completely new capabilities that are required by market forces or regulation – SBOM is the poster child for this group; suddenly, just about every vendor is giving it to you as part of their product.

    No matter which of these axes is growing, the workload is generally growing commensurately. Think about it: If a new product is implemented, it impacts IT’s workload. If a new technology that solves a problem is implemented, it, too, impacts workload. And if a new capability in an existing product is dictated by the compliance team for any reason, this, too, increases workload. This is just the business side, and doesn’t include the fact that most orgs are dropping newly developed applications on a pretty regular basis these days.

    Automation has helped, but it hasn’t solved the problem yet. I believe it can, given time and focus, but for the most part, the demand for new technology to solve age-old problems (“We can’t effectively test” being met with “Here is automated test generation, execution and results filtering”) has been a net increase in workload. Though far smaller than it might have been, it is still increasing. This is true across IT. The test example above applies to app dev and security, with result sets that did not exist six years ago because the process was too expensive in staff hours. It also applies to ops because the processing power to get those tests done – and it is a lot with large test environments – is ops’ responsibility.

    Painting a bleak picture? Nope. Making certain we’re realistic. Trying to ensure that we consider how much we are already doing, and take a chance to implement actual time savers. For example, applying that same test automation to testing (for most orgs, I’m thinking security testing) that was actually being done already will reduce the cost of getting it done. Using SBoM for SCA to contribute to existing compliance saves a lot of time generating that information. Using new coding assistants shortens coding time and (arguably at this point, but inevitably, given the fullness of time) improves code quality, reducing rework, which is costly, even in an agile environment.

    We are growing our capabilities almost daily. I’m just suggesting that, in the process, we backward-apply the good stuff to reduce existing overhead. And as always, this big, complex beast exists and keeps clipping along because you’re there, keeping it fed and stable. Keep rocking it, and save yourself some time by using new technology smartly—there is plenty more to do than whatever you streamline.

    Image source: Photo by Michael Dziedzic on Unsplash

  • It’s Funny How We Forgot About Container Sprawl

    It’s Funny How We Forgot About Container Sprawl

    …Because it sure as heck did not forget about us.

    We are (thankfully) past the days when everything was a container. At least, most of us are. Just like anything else, some orgs will continue that approach for reasons both great and terrible. And all of us still use far more containers than we need, I would say. “One container, one function,” works if you are talking about one whole application, and maybe sometimes for busy parts of an application, but it certainly isn’t needed to host a couple of low-use APIs, for example. My favorite example is separate instances of the same exact application for different teams (not business units – that is a good method to separate business units).

    Thankfully, technology is once again saving us from ourselves and our misdeeds. Processing power is no longer an issue, meaning we can spin up a million containers and keep them running until our public cloud bill arrives. So, it’s not about processing power. I cannot remember the last time that an org was bandwidth-limited, so it’s not about the network. The biggest issue is still security. More containers means a bigger footprint, which inevitably creates more vulnerabilities. Right behind that is container inventory management. What is running where, what images are available and what state are they in, which running containers have drifted from their definition, etc.

    I’m a developer that has sometimes done support for the apps I develop. That means that I laugh at your “Our images do not drift because we’re agile and build-driven.” Of course they do, because troubleshooting is real. The real question is, can you get them back into alignment when the ticket closes? The DevOps toolchain is pretty darned good at that if you let it. Changing a running image and telling no one is a terrible idea that still happens nearly every day across our industry. But technology has brought us drift monitoring. We can be notified of changes as they happen. For those in highly sensitive spaces like FinTech, changes can be blocked in production, but for most of us, we want to know when it is happening and who made the change. And we can get that today.

    Technology has also brought us some wonderful scanning tools from SBOM to SCA to Registry. These tools can give us a list of things for security to worry about in our images. In order to reliably generate these lists, we still have to know what images we are keeping and where—but choose a reliable registry or two, fit them into your DevOps processes and scan on commit. Simple and thorough—as long as everyone uses them.

    Thanks to policy and regulation,  container management tools can offer you a detailed list of not just what instances they’re hosting, but metadata like what image they came from. That helps manage inventory, and by now we are all building hierarchies of images from base to application specific.

    So, we can tell what is running, what images are available to run, how far running images have drifted, what known vulnerabilities exist in both our images and our instances and how compliant we are WRT containers. Dunno about you, but it seems technology has our back yet again.

    You are cranking it out, keeping the lights on, and dreaming of more you could be doing. Use the tools we already have to make it easier and the resulting systems more secure and reliable. You won’t regret it. And once again for those of you whose users never say it: Thank you.

     

  • Technical Debt: Don’t Buy Buzzwords

    Technical Debt: Don’t Buy Buzzwords

    It is absolutely true that the only constant in IT is change. No sooner do a mass of us get the ‘next big new shiny thing’ implemented than people start telling us how much we need the next ‘next big new shiny thing.’ Often, that next big new shiny thing is actually helpful, and we feel (sooner or later) compelled to implement it. Sometimes, the next big new shiny thing is not very useful at all, and yet far too many of us implement it anyway.

    Not naming names here, but you’ve all got technical debt that I would classify as “bling” or “keeping up with the competition” functionality. It’s there; you’re paying for it and/or to maintain it, and yet it provides little value. Sometimes, you’re even forbidden from removing it because it is some exec’s pet project or some corner department is actually using it. You’d just have to replace this version of the next big new shiny thing with a different version.

    And I’m here to tell you: Stop. When considering new technology, the very first thing to do is build a list of the problems you are trying to solve and then describe scenarios where those problems crop up. Then compare the next big new shiny thing–be it features in an existing product or a new space/product completely–to how it solves real needs. People are the absolute worst about this with open source. “It’s free, so let’s try it out.” It. Is. Never. Free. And it is a rare team that tries it out and then removes it if it doesn’t work. Most of the time, they’re off to the next project too quickly to do that level of cleanup.

    SBOMs and SCA are ‘next big new shiny things’ of the recent past that actually help you clean up test/pilot garbage from the latest bout of next big new shiny things. So are containers since you can spin them up, play with the toys and then take them down. I am surprised at the number of teams out there who do not do this, but that’s changing pretty quickly. Use them; it’ll save a ton of cleanup time and a lot of technical debt.

    But most importantly, only buy what you absolutely need. We’ve been dropping an ever-increasing number of tools into the development environment for a decade, and those tools do not (yet) maintain themselves. There is infrastructure cost, possibly licensing cost and staff time. Don’t waste it; focus on what is literally most important.

    And that might mean putting your foot down. We in IT have been loathe to do that since Agile started, but telling a C-level that they don’t need an AI to create new drink recipes (or whatever the current generative AI boardroom craze is) is in the best interests of the company. Focus on systems that help do the work or that protect what does do the work.

    You’re still rocking it, so if rocking the boat a bit in the process causes problems, you might just be at the wrong company or in the wrong role. Achieve, but achieve meaningful results.

  • Low-Hanging Fruit, 2023 Edition: Part Two

    Low-Hanging Fruit, 2023 Edition: Part Two

    Last time, we discussed setting up a comparative inventory system for your growing API footprint. The idea is that as security catches up to new technology deployments, enterprises will have to step up their game and implement those new technologies. API security is currently the biggest need because of exposure to the world, but not far behind it is container security, which we’ll discuss here.

    The point of container security is to make certain that your images are as secure as possible. Container security looks at source container definitions, added libraries and configuration options inside the container definition files ( or for those of you who prefer them, Docker files).

    A Tempting Target

    We are spinning up a bewildering number of containers these days, and having source images–particularly if they come from the outside–is a tempting target to attackers. Imagine if an attacker can hit the base container definition that all of your “golden images” come from and just insert a call to download a library. Soon, your entire application infrastructure could be a tool for that attacker to do as they wish. And if they’re cautious, they might get away with it for months (as many have).

    The Definition of Containers is Security

    So there is absolutely an imperative to ensure that the definition of containers is security–all of your containers. And there is an imperative to know what software is installed via container definition and what software is actually running on container instances. Much like our discussion about static versus dynamic API scanning, bad actors can modify a running container, so drift detection is half the problem, even while scanning registries and definition files has more appeal from the blast radius perspective.

    There are a lot of tools and vendors that range from simply scanning the files and generating an SBOM to complete container security by scanning the images, using the SBOM to perform software composition analysis, using data feeds to determine which software in the SCA is a threat, and how urgent or broad that threat is and monitoring deployed containers for drift. The more of these an organization implements, the more configuration and maintenance effort, but the payoff is security at a more fundamental level. The whole appeal of a container architecture is recoverability–if things go terribly wrong, we can redeploy easily. But if the source files hold the vulnerabilities, redeploying is temporary at best and likely would warn attackers that you’re onto them.

    Be Proactive

    So a more proactive approach is required. Obtain and install tools that will help you protect your container infrastructure, be they sold as container security, cloud workload protection, SCA or something else. The key is locking down this avenue of attack at the beginning of the software supply chain, not where you get the tools.

    And again, keep rocking it. As I said in the other post on low-hanging fruit, we need this because you all are serving the organization’s needs with the best solution for the job. Now that security technologists understand your new problem domain, let’s get tools into place to continue the protection of all that shiny new stuff.