Category: DevSecOps

  • Snyk Acquires DeepCode to Apply AI to DevSecOps

    Snyk Acquires DeepCode to Apply AI to DevSecOps

    Snyk today announced it has agreed to acquire DeepCode as part of an effort to apply artificial intelligence (AI) to DevSecOps.

    DeepCode has developed an interpretable machine learning semantic code analysis tool that scans code anywhere from 10 to 50 times faster than existing approaches. DeepCode currently supports Java, JavaScript, Python, TypeScript and C/C++ programming languages. Developers get started by connecting the DeepCode bot to their GitHub, BitBucket or GitLab accounts or directly within their integrated development environment (IDE). DeepCode then immediately starts reviewing each commit with no additional coding required. The bot is currently free for teams of up to 30 developers.

    Snyk CEO Peter McKay said those machine learning algorithms dramatically reduce both false negatives and false positives as they learn the application environment. That code scanning occurs in real-time, thanks to a Datalog solver developed by DeepCode, which McKay said means code scanning can now keep pace with the rate at which applications are being developed.

    While there’s widespread agreement that more responsibility for application security needs to shift left toward developers as part of any effort to embrace best DevSecOps processes, getting the right security tools into the hands of developers has been a challenge. Developers tend to resent having to wait for security scans to be completed, especially at a time when the rate at which applications are being developed and deployed has been accelerated as organizations embrace digital business transformation more aggressively.

    In effect, code scanning as implemented today is often viewed as a bottleneck. That issue goes away, however, if scanning can occurs in real-time. Armed with that data, it then becomes possible to also prioritize which vulnerabilities to address in code first in addition to in, some cases, automating bug fixes.

    In an ideal world, security will become a natural extension of any quality assurance process implemented by a DevOps team. The challenge right now is bridging a cultural divide between DevOps and cybersecurity teams that have workflows that operate at dramatically different cadences. The more automated the code scanning process becomes at the front end, the fewer security issues will need to be addressed by theses teams as applications are either being deployed or, worse yet, after they are already running in a production environment.

    Fresh off raising an additional $200 million in funding that was used in part to acquire DeepCode, Snyk claims there are already 1.5 million developers using its tools worldwide and that its revenue grew 275% in the last year. Privately held, Snyk claims to have a valuation of $2.6 billion. The next challenge is to expand adoption of Snyk tools across the roughly 24 million developers that are writing code today, said McKay. As part of that effort, Snyk recently formed technology alliances with both Red Hat and Docker Inc.

    Naturally, it may take some time for that goal to be realized. However, with more developers now being held accountable for security, the chances are good that many of them will soon be looking to ruthless automate security in much the same way they are moving to automate every other aspect of IT.

  • Synopsys Report Shows DevSecOps Progress

    Synopsys Report Shows DevSecOps Progress

    A report based on analysis of the software security initiatives of 130 organizations conducted by Synopsys, a provider of static application security testing (SAST) and software composition analysis tools, suggests progress in terms of DevSecOps adoption is being made but there is still a long journey ahead.

    According to the survey results, 121 organizations now ensure host and network security basics are in place, with 73 organizations also monitoring application input.

    However, only 39 organizations said they define secure deployment parameters and configurations, followed by 36 that said they were ensuring cloud security basics and 33 that said they were protecting code integrity. Only 32 had embraced application containers, while 22 employ orchestration for containers and virtualized environments, according to the Synopsys report.

    Using code protection (13), attaching bills of material to application inventory (12) and using application behavior monitoring and diagnostics (7) were even farther down the list.

    Michael Ware, senior director of technology at Synopsys, said the results of the report are an encouraging sign as more software security teams increasingly report into a technology group or CTO rather than an IT security team or chief information security officer (CISO). As the responsibility for application security continues to shift left, IT teams are being reorganized accordingly, he noted.

    More IT organizations are also embedding security reviews within their continuous integration/continuous delivery (CI/CD) platforms as they replace high-friction, out-of-band security tasks with ones that are automatically triggered by events in the CI/CD pipeline, added Ware. That approach also enables organizations to overcome a chronic shortage of cybersecurity personnel that has now become a longstanding issue for most organizations, he noted.

    Longer-term, security will become deeper ingrained in the entire mindset of not just IT teams but also entire organizations, noted Ware. As part of an effort to make the entire organization more resilient to change, organizations are making a more concerted effort to address security issues at all levels of the organization.

    Less clear at the moment is to what degree DevSecOps will be achieved by automating tasks rather than melding workflows. DevOps and cybersecurity teams have distinctly different cultures. As cybersecurity tasks shift left, many DevOps teams will seek to ruthlessly automate those tasks in much the same way they have automated other IT management tasks. In fact, there may come a day when security issues are addressed as a subset of the overall quality assurance process, Ware noted.

    In the meantime, it’s clear much more needs to be done before applications can be considered fundamentally secure. Security issues that stemming from relying on tools to automate the configuration of cloud infrastructure are rampant. DevOps teams clearly need to take more responsibility for security, but cybersecurity teams still need to be able to verify the right policies are being employed. As long as humans write code, there will always be plenty of opportunity for error. The DevSecOps challenge now is to eliminate as many opportunities for that human error to occur as possible.

  • TechStrong TV: Credentials Management, with strongDM and Software.com

    TechStrong TV: Credentials Management, with strongDM and Software.com

    Now more than ever, businesses around the world should pay close attention to how they manage their credentials and control access to their sensitive data, in order to protect it from being hacked or compromised in any way.

    During this interview for TechStrong TV, Mason McLead of Software.com and Elizabeth Zalman of strongDM, discuss the great responsibility of safeguarding credentials and how strongDM has proven to be an effective credentials management tool, helping Software.com to control access and keep their data safe, even when working from a remote environment.

    Software.com is a data platform dedicated to help developers and engineering teams learn from their data, increase productivity and improve their coding routine.

    Check out the interview below and follow along with the transcript to find out more.

    Transcript

    Alan Shimel: Hey, everyone, thanks for joining us on another episode here of TechStrong TV. We’ve got our recurring guest friend, Elizabeth Zalman, of strongDM joining us, here—hey, Liz.

    Elizabeth Zalman: Hey, Alan.

    Shimel: And joining—hi—and joining Liz and I is Mason McLead of Software.com. Hey, Mason, welcome to TechStrong TV.

    Mason McLead: Hey, thanks for having me.

    Shimel: Alrighty. So, Mason, you’re the new kid on the block, and we’re gonna give you a chance to lead things off. I think a lot of our audience has certainly heard of Software.com if they’re not really, really familiar with it. But for those who aren’t, you know, why don’t we give them a little background?

    McLead: Sure. I mean, high level, Software.com is a developer data platform, and our aim is to create and provide insights for productivity for individual developers as well as engineering teams. And we do this by gathering telemetry data from inside of code enders and then layering on contextual data from other parts of the software development life cycle, like how many hours you’ve been at meetings, what kind of music do you listen to while you code, do you code during work hours, after work hours, at the office, remotely—and then really pain the full picture of where your time goes and how it’s impacted by these external inputs. And that’s what we provide back to developers as kind of the product there, so you can really see how your time is impacted and what you’re doing throughout the day in order to improve.

    Shimel: Very cool. And then, Mason, we should tell people or at least give them a little background—what’s your role at Software.com?

    McLead: Yeah, so, I’m the CTO here at Software, just joined this year. And you know, it’s an exciting time to join in. The product’s been out for a while, and so, there’s a lot of proven track record and it’s just taken to that next level, and I’m excited to be here.

    Shimel: Very cool. And, you know, we do have Liz from strongDM here, so the obvious question is, you guys are using strongDM, I’m gonna assume. Talk to us—why? What’s happening that strongDM was a solution for you?

    McLead: Yeah. I mean, the main thing—and this is actually the second time that I’ve signed up to use strongDM. I used them before at my previous company I worked at, Fair, it’s a fintech company. And the real premise is that, you know, at Fair, it’s in fintech, so we gather a lot of personal information. At Software, it’s a lot of information about your behaviors and all of that stuff.

    And it’s just personal information, and I feel like, in the role that I have of being CTO, I have a responsibility to protect that, and I really, personally, feel like it’s a moral obligation to protect my users’ data. And strongDM helps me do that in a number of ways. And so, it’s been a rock steady foundation that I always build into the tech stack whenever I go and build something now.

    Shimel: Excellent. So, you know, you opened the box, we gotta see what’s packed inside—what are the number of ways why, you know, you can’t just leave us hanging there.

    McLead: Sure. [Laughter] Yeah, I’ll enumerate. So, for getting access to developers—and the classic way that you do it for databases, right, is you have credentials that you share amongst however many developers need access to that database. Which means, as soon as you rotate that password, if you do, then you’ve gotta update everyone else. And now you’ve got copies of passwords everywhere on people’s local machines. And not everyone stays at a company for their entire life, so whenever they leave, you must do something about that. Like, that credential is now out in the wild, and there’s not very many good tools to manage that.

    So, strongDM really fills that gap really, really nicely, that use case. So, we can issue credentials automatically for people as they come on. We use Gusto for our HR stuff. So, if they’ve got an API, we can just—as soon as someone comes online, we can issue them credentials to data stores immediately. And then, if they go offline to their contractor, they’re immediately revoked. And the perimeter of the security just gets really tight and really well controlled, which is such a relief for me.

    And then on the other side, securing access to servers via SSH, and we’re also deploying a new Kubernetes cluster, controlling QTTL access, and having all of that be auditable, because we also have some contractors working on our database so we can see what commands they’re running, what queries they’re running, and be able to trace that all back. And being—like, most of the time we’re not, of course, looking at the audit trails. It’s really, like, knowing that it’s there if something happens, we’ll know exactly how to trace that back.

    Shimel: Love it—very, very good stuff. And, you know what, I applaud your personal, you know, taking this, I’m gonna call it fiduciary duty or responsibility for safeguarding people’s really personal data—you know, for taking it personally like that, no pun intended. And, you know, maybe if more people did, we’d be better off.

    Though, look, no one ever raises their hand and says, “I wanna be breached,” right? And even sometimes doing everything you can, it’s still not enough in order to prevent these things, but you can certainly take precautions, you can make it harder by using tools like a strongDM and so forth. So much—I had a friend of mine call me last week, an old client of mine from my security days who, unfortunately, they got to pretty bad. They got into his Charles Schwab account, they got into his payroll account, they got into all of his e-mails. And he’s in the merchant processing business, so there was merchant applications—it was crazy. And, you know, he was beside himself. On the other hand, he didn’t use a password manager—you know, typical kinda things you hear. So, it happens.

    Anyway, but it’s interesting, you know, that across verticals, right, from fintech to what you do now at Software.com, though the mission may have changed in terms of the business, you know, goal, the mission in terms of protecting data hasn’t, is still relatively the same.

    Liz, is this—is Mason’s experience, Mason’s motivations typically, you think, for strongDM customers across the board?

    Zalman: I think our customers feel deeply that there is—our customers feel deeply that there is a right way to do things. I think Mason, as an early customer of ours and at Fair, I think came in it from day one, just had a very particular point of view on how things should be done. I think he was actually one of the first customers to even be deploying Kubernetes in a production environment.

    And so, our buyer is the head of infrastructure or infosec or DevOps as a way that they want to do things, it’s always very forward thinking. And finding a way to do them in an automated fashion that sort of fits into these, you know, Infrastructure 101, the ABCs of how to set something up in a way that helps them scale is probably a core precept that they have. I mean, Mason, how big are you guys now at Software when you inherited the team?

    McLead: When I inherited the team, there were five other engineers and we’ve grown that up by about 50%. So, it’s still small and growing, but you know, I think no matter the size, the problem is still the same. And, for me, the solution’s been the same, too.

    Zalman: Yeah. Yeah, so, at Fair, I think you guys were maybe 100 people who were touching some form of infrastructure, and here, Mason’s starting, he started at six. So, yeah, certainly, it’s like, when you know that there’s a good way to do something and a right way to do something, you start it right at the beginning.

    Because, to do that when you’re a thousand people is—you can do it, but it’s a two year process of rinse and repeat sort of work group by work group. You do it right from the start and you’re off to the races.

    Shimel: Well, if we all had the luxury of starting in a green field, right, and starting it from the beginning as it grows—what a wonderful world it would be, as they say. But unfortunately, we don’t, right? There’s a lot of brown field—muddy brown fields out there.

    Mason, let’s talk a little bit—and Liz as well—let’s talk a little bit about, you know, so, this whole COVID thing comes up now, right? We’re all here, you guys are in your houses doing this interview—what, if any, effect has that had on the business and has strongDM helped, hindered, not been a factor in that?

    McLead: Yeah. So, actually, Software.com was fully remote from the very beginning. So, internally, it hasn’t made a big difference in how we work. I think it’s an upgrade—like, going to strongDM for access control is an upgrade, no matter how you work. I think it’s probably more important whenever you’re remote—I mean, people have central VPNs and those sorts of things, but it’s still, building that defensive wall in strength and depth is still the right move there.

    And so, internally, it hasn’t affected us too much, just because of the way the company is set up. For the business itself, though, it actually highlights a big advantage that we can provide as part of our products, of being able to see productivity metrics between remote and in office. Because people are gonna have a big choice coming back in from COVID whenever this is resolved of how much office space do I actually—do I need an office? And then how do they actually guide that discussion and that decision when you don’t have data around it? And that’s where we can really fill a gap there between knowing how people are working remotely and how they’re working in the office, so you can have a real comparison.

    Shimel: Wow, what a great use case that is. I’m sure that was one of the use cases they drew up when they were starting the company, right? If there’s a worldwide pandemic and everyone’s working from home, wouldn’t it be great to know how well they’re working from home?

    McLead: Yeah, it’s amazing the foresight we had. [Laughter]

    Shimel: Yeah. But, nevertheless, it’d be nice to have there. You know, I wonder about that issue, question myself, though. I mean, here, you know, we’re a small company, we’re about 23, 25 people, and everyone’s remote now except for me and my video director and, you know, we’ve—we have three and a half years left on our lease. Actually, September, it’ll be three years, so three years left on the lease. So, I’m stuck with, you know, this for three years. But I don’t see people running back, and if they do, they might just come in a day or two a week.

    And, you know what? That’s fine. As the CEO here and founder, it’s fine with me. We’re working fine remotely. No one needs to necessarily be here to do their job, though I do think there is—there is some good you get from having people in the same office, whether it’s the water cooler or hallway talk or what have you. But that is—you know, that’s the new normal, that’s the new now, and I think we need to get used to that.

    Liz, you know, again, in any situation there are winners and losers. But this whole COVID thing has—you know, not your fault, obviously, right, but it’s given people a reason to say, “Jeez, I need something like a strongDM,” right? “I want to spin up my remote force” or, “I want to—we need to secure it better” or what have you. What are you hearing from companies? You know, Mason’s a two time user already—but first time people, what are they saying when they come by?

    Zalman: Yeah, Alan, I am the mastermind behind COVID, you just—

    Shimel: Yeah, exactly. [Laughter] Dr. Evil, okay—we got ya! [Laughter]

    Zalman: No, yeah, Mason is certainly in a subset of companies that enjoys being remote from the start and being able to build that way. We saw a doubling down of an existing customer base where even if they had remote or satellite teams, now everybody became distributed. But also, new people reaching out because traditional companies, you can’t rely on the corporate network as a perimeter any more. It’s dead. It’s just—it’s completely gone and you had to switch on a dime, and what do you do?

    And I can’t even imagine—you know, by deploying strong, oftentimes, you can just throw out the VPN. Many customers choose to do that. And I can’t even imagine what these poor IT folks were dealing with in old companies who, you just had to go into the office, there was no other way of working, all of a sudden getting all these requests, “I can’t connect to the VPN” or any sort of IP-based white listing. Oh, my God, to get access to privileged systems? My heart goes out to them.

    Shimel: Yeah. No, you know what, I actually did an interview last week from an analyst based up in Canada who just put out a report about, you know, how COVID caused a short term increase in people buying concentrator licenses and more VPN capacity, but how long-term, that’s probably throwing good money after bad in terms of out the window. I mean, you gotta just—you gotta re-architect is the bottom line, there.

    But it’s hard to do an engine transplant in the middle of the race. And so, people get stuck, you know, in those situations.

    Zalman: Well, as one of my investors is fond of saying, “You gotta build the Ferrari while you’re driving it.”

    Shimel: Yeah, and that’s—ain’t it the truth? I hear ya. Mason, what about you guys at Software.com? I mean, are you just ready for the new normal here and you were remote, anyway? Because there’s a part of—look, we can function in this environment, that’s fine. But are your customers functioning in this environment? Because ultimately, if they cease to function, no matter how high functioning you are, you know—big deal.

    McLead: Yeah. I mean, developers are customer based, so we’ve got to make sure that is continuing to function, yeah. You know, we’ve actually taken surveys on this for our customer base, which is nearing about 100,000 and the majority actually said that they would want to do a bit in the office and a bit remote. So, kind of a mixed use case, there. And I think that that fits really well to get the advantages of being able to control your own schedule and control where you are with the in person being able to white board together, being able to really come together and think of new ideas and I remember all the hours that I spent in the office at Fair with a tight group of people developing all the stuff that we did there, and there are definitely some advantages to just being able to randomly yell out to the person in the other room to go and fix something.

    So, you know, I think that it’s gonna be a mix of that, and you’ll have some people that’ll wanna go full remote once they’ve had the taste of it. Like, I really enjoy it. Like I said, and you can tell by the bare room behind me, I’m moving this week, actually, and it’s really interesting to start to feel the effects of being able to live anywhere and work the same job. Like, having it completely disconnected is a new feeling for me, and it’s weird, but I like it. And so, you know, I think [Cross talk] –

    Shimel: I think we’re gonna see it.

    McLead: Yeah.

    Shimel: Yeah, no, I think—look, I read an article, I forgot what percentage rents in San Francisco are down, right? I think we’re gonna see rents going down in a lot of the cities because people are realizing where they work from physically is not necessarily tied any more to where the company is based.

    Now, you still want to hire people with skills in places like New York and San Francisco or Austin or Boulder. They still have high concentrations of people with skills, so it pays to maybe put an office there. But, you know, I’ve had this conversation with Sid Sijbrandij, the CEO/founder at GitLab. They got, like, 1,200 people in 1,200 offices, because they don’t have an office. Everyone, including Sid, works from home, and his thing is, you know, for newer companies, it just doesn’t pay, because you know, once you put an office down, you’re saying, “That’s it, I’m only gonna—I’m confined to that talent pool.” Where, if you wanna swim in—you know, have choices in a wider talent pool, you’re not big enough to open an office wherever you’ll find talent.

    And so, you know, a remote force is probably the way to go. I mean, good for Liz and the strongDM team, right? But that’s—I think that’s part of where we might be headed.

    McLead: Yeah, and I think if you limit yourself to one specific geographic region to hire from, you’re limiting the upside of your entire company.

    Shimel: Yep.

    McLead: And incurring costs along the way. [Cross talk]

    Shimel: Absolutely.

    McLead: For the corporations that can do it.

    Shimel: Right, I think that’s an outdated look.

    McLead: Yeah, I think so.

    Shimel: You know, I think that’s where we’re headed. Anyway, guys, we’re about out of time. Mason, I told you the 20 minutes goes quick, because usually Elizabeth talks so much, she takes over the whole conversation—no, she doesn’t. We’re just kidding.

    But I’m gonna give you each a chance to say something before we log out, here. Mason, you’re the new kid on the block, so why don’t you go first?

    McLead: Okay. Well, again, thank you for having me on, and it was a pleasure to talk about what we do at Software where it’s a developer data platform designed to help developers individually to see where they’re spending their time, look at productivity metrics, and improve, as well as helping manage the entire software development life cycle from input all the way through output. And thanks to Liz for strongDM and strongDM for a great product that helps us secure our data. It’s definitely a huge benefit that I put into every stack that I build now.

    Shimel: Very cool. Elizabeth, I’m giving you the last word.

    Zalman: I think Mason just summed it up for me, although I think my hair is better than his, so, I’m gonna retain that for me. [Laughter] [Cross talk]

    Shimel: I think both of your hair is better than mine, and we’ll leave it at that. [Laughter]

    Zalman: I don’t know how his looks so tight—dude, who’s cutting your hair?

    McLead: I cut it. I learned how to—I watched YouTube. I missed this part here, but—

    Shimel: Yeah, no—you know what? I think that’s been a thing. I mean, yeah. It’s easier for guys than it is for gals, I will say that.

    Zalman: I commend you, Mason, both on your haircut and your choice of infrastructure technology products. [Laughter]

    Shimel: Very cool. [Laughter] Guys, on that note, we’re gonna call it a wrap. This is Alan Shimel for TechStrong TV. Elizabeth Zalman from strongDM, Mason McLead from Software.com—thanks for being our guests. We’ll be right back with our next interview.

  • Safeguarding Secrets Within the Pipeline

    Safeguarding Secrets Within the Pipeline

    How can an organization write source code to use secrets without directly referencing them and risking them being leaked to the public?

    2020 closes out a decade full of countless code leaks, a topic we talk about quite often. In fact, just recently, Intel became the latest victim after 20GB worth of internal documents were leaked and uploaded to a public sharing site.

    Intel finds itself in good company as it joins a long list of 2020 victims whose confidential source code has involuntarily gone public.

    Many, if not most, of these victims share one common fatal flaw: They hard-coded secrets (logins, tokens, etc.), then published their source code to a trusted cloud computing service platform such as an online Git repository.

    It would be naive to lay blame solely on the platform, however. It has long been a reliable rule of thumb that anything you put online—gated or not—is always at some level of risk. With this in mind, one should never, under any circumstances, include secrets in their source code. Stealing source code is damaging enough; the keys to your kingdom should not be included.

    That’s easier said than done, of course. How do you write source code to use secrets without directly referencing them? In this blog, we’ll show you an overview of how you can utilize your continuous integration and delivery tools to inject secrets into your code at build/runtime without actually including them in the code itself, thus placing a veil between your code and your secrets.

    Injecting Secrets

    One method for publishing source code reliant on secrets without actually including the secrets in the code is to use placeholders within the source code which, at build time, are replaced with the actual values needed.

    Microsoft Partner Technology Strategist Primoz Kocevar details such a method in his Medium post. The general idea is that secret variables are provided to a Docker image so that no secrets are found within the source code itself.

    An environment variable, set up beforehand, stores the secret. This variable is defined in a Docker file, which is used to create an image. During the build phase, secrets are then passed via the Docker image through the variables specified in the source code. Once complete, the application and image can be deployed.

    If you happen to run your images on Kubernetes, you can also leverage its own feature for securely storing secrets. This method allows you some additional options, such as using a Kubernetes environment variable or ConfigMap within a Kubernetes pod to store secrets for injection at build time.

    By the way, this approach to secret injection is by no means exclusive to Docker or Kubernetes. Though we highlight them here as specific examples, the same method can be employed via virtually any similar solution you rely on for deploying pods or containers.

    Injecting secrets via clever use of environment variables and configuration files in your microservices platform of choice is certainly a viable option, but we don’t think it’s the best option. Consider that this approach requires one image per each secret.  This can get cumbersome fast if you have a development environment with one secret and a production environment with another secret, each requiring different images.

    Leveraging Your CI/CD Tools

    First, a quick primer for the uninitiated: Continuous integration (CI) and continuous delivery (CD) tools and practices are an essential part of the larger software supply chain. Continuous processes are those that enable developers to publish code changes easily and frequently without degrading the product’s reliability.

    Continuous integration tools and practices establish uniform processes for creating, testing and building source code, integrating with any required external systems along the way. Continuous delivery covers the activities that follow, streamlining and automating the delivery of source code to infrastructure, especially when multiple multiple environments are involved.

    Many CI/CD tools provide their own built-in solutions for securing sensitive data. You can leverage these features when storing secrets until it’s time to inject them during the build.

    For example, Jenkins provides its own credentials store and its own automatically encrypted Secret field type. (A word of caution: This alone doesn’t prevent a user from accidentally printing a secret in the console log.)

    Another CI tool, CircleCI, offers a number of options for protecting secrets, such as secret masking to prevent secrets from appearing in terminal output and contexts, which limit access to certain variables to only specific user groups.

    There are, of course, as many additional options as there are tools available.

    We can leverage such features to enhance our previous example: secrets stored in your CI/CD tool can then be injected into our Docker run command (or your platform’s equivalent command) during deployment. In other words, your CI/CD tool of choice injects secrets into the image, which in turn injects the secrets into the corresponding source code’s variables. This method ensures our secrets never appear in the actual source code.

    A word of caution: Even utilizing this approach, your secrets are still only as safe as the tool you use to secure them. The Bleeping Computer article we linked earlier in this post points out how weakly configured tools themselves pose a threat: “The leaks have been collected by Tillie Kottmann, a developer and reverse engineer, from various sources and from their own hunting for misconfigured DevOps tools that offer access to source code” (emphasis ours).

    It’s important to stress the universal rule that there is no such thing as perfect security. Consider that encrypting your secrets within one of these tools offers little protection if access to those tools is not sufficiently restrictive. We recommend cautiously limiting who is granted what level of user access to each tool, applying the least privilege principle.

    Protection Post-Deployment

    Now that we have built and deployed our secret-free code, what’s next?

    If we were to stop here, we would have overlooked the fact that any developer who has access to our containers can see our secrets. The downside to utilizing a microservice infrastructure is that there are many opportunities for security gaps to appear between all the moving parts, from the moment the first line of code is written to when it all goes live, which can easily go unnoticed.

    Containers and pods need to communicate with each other and other endpoints, thus an attacker can leverage this by compromising one container or pod then moving laterally to others, rendering any secrets stored within ripe for the taking. The bigger your distributed infrastructure, the more difficult this is to prevent, because of the inevitable complexity of security policies required to do so.

    Thankfully, many tools offer options such as built-in network/firewall policies between containers/pods and endpoints, an option to encrypt data at rest or a mechanism for enforcing the least privilege principle, such as via restricted security groups.

    Some tools may also allow you to configure a Key Management Service (KMS) provider to encrypt your secrets. A KMS provider employs an envelope encryption scheme for data stored within etcd. The added benefit to this approach is that the decryption key is stored remotely on the KMS as opposed to on the same host.

    Conclusion

    Regardless of what tools you have in play along your development pipeline, secrets must always exist outside of the source code and should be (securely) injected into the code as it passes through the pipeline.

    Wherever secrets ultimately live, be it in a remote storage location, a container or pod or within a CI/CD tool, they must always be encrypted and never stored in plaintext.

    Finally, all the obfuscation and encryption in the world will not protect secrets from a lackadaisical user access policy. The least privilege principle should always be in play and user security groups should be strictly managed to control who has access to the systems responsible for securing your secrets.

    All that said, mistakes still happen, and none of the tools discussed here perfectly ensure that no developer will nonetheless accidentally hard-code secrets into your source code. It is with that in mind that we advise adding another layer of security by automatically monitoring your source code repositories for secrets.

  • TechStrong TV: strongDM Helps Kustomer Go Remote

    TechStrong TV: strongDM Helps Kustomer Go Remote

    For a procurement process to be effective, the relationship between the customer and the product team is almost as important as the functionality and features of the product itself.

    During this interview for TechStrong TV, strongDM CEO Elizabeth Zalman and Steve Flinchbaugh, senior SRE at Kustomer (a customer support CRM platform for managing high support volume effortlessly), talk to us about the strong bond between the Kustomer team and the support team at strongDM.

    Steve explains how Kustomer uses strongDM to empower its remote teams, how it fits into their development workflow and how strongDM has made his and his team’s lives easier.

    strongDM allows remote teams to easily manage access to databases, servers, Kubernetes clusters and web apps.

    Check out the interview below and follow along with the transcript to find out more.

    Transcript

    Alan Shimel: Hey, everyone, thanks for joining us for this next session here on TechStrong TV. This is gonna be a really good session; it’s something we haven’t done before. I have two guests, which we’ve done before, but we’re really gonna zero, we’re gonna take two different companies and see how they interact and how that helps, especially given everything that we have going on around us.

    Let me introduce my two guests to you first. First of all, we have Elizabeth Zalman. Elizabeth is the CEO of strongDM. We’ve done—I think we’ve done at least a podcast and so forth with strongDM before. Liz—hey, welcome, thanks to TechStrong TV.

    Elizabeth Zalman: Thanks, Alan. Nice to be here.

    Shimel: Thanks for joining us. Okay, and then joining Liz and I is Steve Flinchbaugh. Steve is with a company called Kustomer, and that’s spelled with a K, and he’s gonna tell us about it, as well as his position and background there.

    Steve, why don’t we start off with you, okay? Kustomer with a K—what do you guys do, and what do you specifically do at Kustomer?

    Steve Flinchbaugh: Sure, Alan. Thank you for having me. So, I’m a senior SRE at Kustomer, and what Kustomer is, is a CRM for customer support. And we really are built off of our platform. There’s a lot of intelligent automation that allows our customer service teams, our customers, to give the best possible customer experience they can and accomplish their customer service goals through, ideally, less staff and less effort using our platform.

    My goal as the senior SRE is to ensure the reliability of our platform, the kind of implicit trust that everyone expects, and to make the job for our developers as easy and seamless as possible.

    Shimel: Cool. So, a real, live SRE right here on our show—very cool. You know, there’s a lot—I don’t know if you guys have seen, there’s been a lot of articles written lately in the press around, you know, are we overblowing the whole SRE thing, right? And is it real, how real, and where does it fit in and all of these other things.

    But anyway, Liz, we gave Steve a good chance to tell us about Kustomer with a K. Let’s give you your chance—tell us about, remind our audience about strongDM.

    Zalman: Yes. Steve is one of my favorites, by the way—so is Kustomer with a K. They’re one of the most forward thinking customers with a C that we have. [Laughter]

    Shimel: Okay. Very good play on C/K, there. [Laughter]

    Zalman: strong is a—it’s a proxy, it’s a control plane, it’s insert whatever word you want there and it lets you manage and audit access to servers, to databases, to Kubernetes clusters, to whatever infrastructure you’re running that is firewalled. So, typically, that access is managed by hand, or keys are sitting in a box or a vault somewhere, and we let you collapse all of that down into a single control plane for both the management and auditing of that access

    Shimel: Yep. And I just—look, I feel like we have to mention that, you know, given the whole COVID situation and working from remote, you know, strongDM has been a real godsend to a lot of companies who had to kind of flip a switch and empower remote people to have access and stuff that, you know, from a different place on different machines, devices than they had before.

    So, though strongDM had a great case before COVID, right, a great use case, post-COVID, Liz, how many—you know, I’m not asking for the amount of customers, but I mean you’ve seen a lot, I imagine you’ve seen a lot of activity from customers who are, have switched to remote and need help with that.

    Zalman: Yeah, certainly, it was challenging before. I think most companies today have remote workers, anyways, or multiple office locations. With the lockdown with COVID, I think what ended up happening is, for companies who rely on the corporate network itself as the perimeter within the building, that perimeter is now gone, and so, what do you do? If you’re using something that’s IP-based, all of a sudden, your IP surface area went from, like, two to 5,000 if you’re an enterprise.

    So, we certainly saw a doubling down of existing customers and an increase in interest in the product. I might ask Steve, like, could you have imagined what—I mean, what was it, like, you guys have an office in New York…do you guys have remote workers? I don’t—yeah.

    Flinchbaugh: Yeah, so, we have an office in New York and we recently—that’s our headquarters—and we recently acquired some office space down in Durham, North Carolina. That’s kind of our first official outpost, and that was kind of our introduction to people outside of New York, and it was—this was after we had adopted strongDM, and I have to say, it was entirely seamless. And ever since the pandemic began, I know it’s good because I haven’t thought about it that much. strongDM is—

    Shimel: That is always the sign. You know what—sorry—I was in security for 20 years. They didn’t call it cyber then, it was InfoSec, but we always used to say, “If they didn’t think about it and it didn’t hit anyone’s radar screen that they—you know, that was a good thing.” When people hear about security stuff, it’s because something bad happened.

    But I wanna make a point here, though, and that is—Steve, it’s my understanding you guys didn’t, you’re not a Johnny come lately to strongDM. You guys were using this well before COVID and the present situation. Talk to us—let’s go back in time to then, it was about a year and a half ago, right?

    Flinchbaugh: Yeah. And actually, if you don’t mind, I’d like to go even further back in time, about four years ago—

    Shimel: Be my guest.

    Flinchbaugh: – when I joined Kustomer.

    Shimel: Okay.

    Zalman: You joined it four years ago?

    Flinchbaugh: Four years in September.

    Zalman: Wow! How big were you then?

    Flinchbaugh: I was, I think, employee number 16. We were still in stealth mode, we weren’t charging our customers yet, and Steve comes into Kustomer bright-eyed and bushy-tailed. But at this time, we were running agents on our servers to provide SSH access to our engineers, and I was charged by the CTO to stand up a VPN, which I had never done. And this came in the form of open VPN, and I had to manage the certificates and the log-in and the users and every employee that joined the company, I had to on board them and configure a profile.

    And then, fast forward to, I think it was about a year ago, where the CTO again came to us and said, “Hey, there’s a really cool company that I think we should take a look at. We have a mutual investor, and they have a lot of cool features that we haven’t had for the past three years.” So, we had a couple really cool meetings with Liz and her team. I could immediately tell that we were working with a team that knew what they were talking about, they were technical, they were fun to work with and they kind of just got what we needed out of the tool.

    And now, today, there are so many things that are taken off of my plate in addition to more features for security and making developers’ lives easier that strongDM now gives us.

    Shimel: Very cool, very cool. Alright, now, we can fast forward to Durham and how strongDM helped with the rollout there of a new—I don’t wanna call it a remote office, but I think you used the term outpost?

    Flinchbaugh: Yeah, so, it’s definitely, like, our—we call it HQ2, I believe, but we’ve got a fully functioning, we call it squad, so we kinda have self-sufficient and cross-functional teams out there, and everywhere across the country, but Durham was our first remote squad, if you will.

    And the neat thing about strongDM is, I don’t necessarily have to say when a new user joins, when someone joins the company, there’s not necessarily a task in my to-do list. It’s so self-service with our Okta configuration, a user can go in and say, “Hey, I wanna start using strongDM, I’ve heard all about it. How do I get access to our data storage and our private resources?” And at that point, I get an e-mail, I can add them to a roll, to a group, and they’re happily on their way. So, I don’t need to configure a profile, I don’t need to do anything special for these individuals. So, from my perspective, it’s incredibly easy to onboard new and remote folks.

    Shimel: That sounds like too good to be true. Is it true, Steve?

    Flinchbaugh: [Laughter] It does feel too good to be true sometimes.

    Shimel: Okay, and you’re saying you guys use Okta for a lot of your IAM and stuff like that?

    Flinchbaugh: Yeah, part of our maturation as a company, you know, back in the day, we had, of course, authentication and identity all over the place and now it’s much more unified. All of our tools that can integrate with Okta, it just makes it that much easier. And again, it’s just things that I don’t have to think about as often

    Shimel: So, Liz, let me throw something back at you. Again, the whole IAM space is something I’m somewhat familiar with—how important is it for strongDM to integrate with an Okta or ADs or other kinda directories and stuff like that

    Zalman: It’s critical. It’s one of the core principles of the business. I think, you know, I’m guessing, Steve, the customer made the decision to buy Okta well before strongDM.

    Flinchbaugh: I think it might have actually been around the same time—but yes, I think Okta was shortly before strongDM

    Zalman: Yeah, so, you have to start with the question of, “What is my identity store? What controls identity, and then how do I integrate that identity store with everything else?” So, strong has integrations with all of the SSOs—because I don’t want to reinvent the wheel. Steve’s already invested a bunch of money in Okta. He’s already reinvested a whole bunch of money in whatever he’s using for automation, Terraform or otherwise or an Amazon tool. Most companies have already invested a whole bunch of money in Splunk or Sumo Logic or QRadar, whatever they’re using for logging, I don’t need to reinvent the wheel with logging and alerting, I just need to make sure there’s a connector between the two.

    And so, honoring what people have already invested a whole bunch of money in and sort of bet the farm on already is critical.

    Shimel: Yeah, you know, Steve, you’re an SRE, so you live this every day. But it’s something—I’m an observer now. My days of those battles are over, right? But as an observer, it’s still, I shake my head sometimes, because so many companies like Kustomer, right, have kinda made their bets on the tools that they use, right? They’ve put together an identity in access management, but it’s not log management, cloud platforms—you know, your whole tool set. But yet, there are still plenty of companies who are trying to say, “No, no—you should use us for everything, right? We can sort of do what strongDM does.” You know, and you know the old saying with this, right? They try to give you 80% of the functionality for 40% of the price, and if that’s good enough for you, it’s good enough, right?

    And I was never a fan of that model—Liz, you’re laughing; what do you think? I mean, we see this still, and I don’t—you know, I assume some companies go for that, you know? But I can’t imagine it really works out. You just don’t get the function—we live in a great time where there’s so much available to us to try to make lives easier for people like Steve, for the SREs of the world and the Ops folks. You know, why would you try to just shove everything into one vendor and do, and put up with less than.

    Steve, what do you think?

    Flinchbaugh: So, it’s definitely, when you’re a smaller company, it’s, of course, much easier to adopt and drop and try new technologies and vendors. But, of course, as we’ve grown, that cost becomes higher and higher. So, when I first joined Kustomer, we could try new things whenever we wanted, but I can already see in the couple years that I’ve been with the company that implementing something like strongDM would be almost exponentionally more effort now, because I’d have to go through different departments and accounting and finance and communicate with the team, and developers just wanna know, “How do I do my job? Like, just tell me what to do.”

    Shimel: Mm-hmm.

    Flinchbaugh: And more than the functionality and the features of the product, I truly feel like we have a relationship with the strongDM team, and that’s almost just as important to us. We know that they are responsive, that they’re gonna listen to us, that they’re gonna help us out—and they have, you know, literally weekly.

    And that is so important to us as customers that, if someone came along and said, “Hey, we’ll charge you 50% of the price that strongDM does,” I don’t think I would be too tempted to consider that right away.

    Shimel: Yeah. But I think that goes to the model today, right? It’s part of this whole cloud native, open source, freemium core, open core, whatever you wanna call it, which is—the key is not to go hire some enterprise sales guy who comes by and wines and dines people. It’s about—hey, here’s the product. Let me get the product in your hands, right? Let me deliver delight, as they say, right, with that product, and the bonds that are formed from that type of relationship, right, it’s—if you wanna call it DevRel, you know, a lot of people call it developer relations and community relations—those sort of bonds are much stronger than the old sort of sales game that I grew up in, for instance.

    Elizabeth, with what Steve is saying, is that sorta news to you that it’s much easier to get in and kinda grow with these customers than it is to kinda come in when they’ve reached a certain scale and it’s a lot harder to get adoptions done

    Zalman: Certainly, it’s easier when a company is young—50, 100, 150, even 200—to get implemented. I think to Steve’s point, eventually,  you have a procurement department, and then you have to go through the traditional, like, “Oh, that’s the price? Okay, we’re gonna knock it down by 50% now,” right, and that’s just how the operate.

    Shimel: Right, yeah. Mm-hmm

    Zalman: And certainly, there are much longer sales cycles in the enterprise side, with a company of Kustomer’s size. Even the size today, you know, two week POC and you can play with it enough, to your point, Alan, where you decide if it’s right for you, if it fits enough of your requirements.

    With larger enterprises, it’s—and again, to Steve’s point, it’s not…you do have to go team by team, right, at a larger enterprise and say, “Okay, we’re gonna do the finance team now, and then we’re gonna do the engineering team, and then we’re gonna do the DevOps team.” And it’s sort of rinse and repeat and you get the hang of it after a while, but it’s bite sized chunks, always, whether the bite sized chunk is the entire company at once, or work group by work group.

    Shimel: Yeah. And I think that very much mimics the whole DevOps adoption pattern as well, right? You don’t go in and just turn on a large enterprise to DevOps, you do it bubble by bubble, team by team, right? And quite frankly, the other thing is, though, is I will tell you that sometimes that procurement process and all the b.s. that goes with it is why developers or DevOps people will whip out a credit card and just do it, right? And you get the whole shadow IT thing or whatever you wanna call it, but it’s like, who wants to—you know, I gotta sit and explain to this person why strongDM makes my life easier? You know, I mean, it’s—especially someone who has no technical background, it’s like, you know, where do I begin?

    But, you know, nevertheless, you guys got a year and a half of history here. Steve, where do you see the first squad’s in Durham, I assume that means you guys are planning second and third squads and maybe outside the U.S. and what have you—is strongDM tied, I imagine, tied into that as the roll out moves along here

    Flinchbaugh: Yeah, of course. It’s become the way that we access our resources across all of engineering. And we actually acquired a Spanish company, Reply.AI, a month back.

    Shimel: Oh, very cool.

    Flinchbaugh: Yeah, so—

    Zalman: Congratulations

    Flinchbaugh: Thank you. So, I’ve been having some conversations with the Reply engineers, and I can already tell that they’re impressed with how we use strongDM and how it kind of fits into our development workflow. And so, that would be interesting, because they have infrastructure of their own, infrastructure that we haven’t used before, so it would be a cool opportunity to say, “How does this plug into strongDM?” And I really have no concerns that that would be the case, but it’s gonna be a fun task to get all of that in the same kind of workflow that all of our Kustomer engineers use today.

    Shimel: Excellent. When you say Spanish, like in Spain—they’re based in Spain?

    Flinchbaugh: Yeah, they’re based in Madrid. I believe they’re a fully remote company, though, throughout Spain. So, they kinda have that remote culture, already, so it’s perfect for us right now, and of course, their AI expertise is nice to have, as well.

    Shimel: Absolutely.

    Zalman: Steve, where is their infrastructure? Like, is it in the U.S. in AWS or is it in something sitting in Europe?

    Flinchbaugh: I can’t say too definitively, but I do know that they have a mix of AWS and Heroku right now.

    Zalman: Interesting.

    Shimel: Really?

    Zalman: So, you’ve got a distributed team in Europe and now, effectively, multiple data centers if you’re talking AWS and Heroku that aren’t merged with Kustomer as well—

    Flinchbaugh: Yes, indeed.

    Zalman: Yeah, I see.

    Flinchbaugh: That’s right.

    Shimel: Sounds like an opportunity, Liz. [Laughter] Liz, let me ask you a question—how many, I mean, what I’ve always loved about the Internet is, it knows no borders, frankly, right? I remember the first time I put up websites and I started seeing hits come in from around the world. This is, like, 1996, and I was like, “Wow, we’re global!” Not at Media—you know, not this company, obviously.

    But what is the customer mix at strongDM? Is it international or is it mostly U.S., or—if you know?

    Zalman: Yeah, it’s heavily international. We’ve got, actually, a big contingent in Australia, we have Europe, we have Asia. Our large enterprise customers all have offices in India, whether they’re using contractors as a work force or an actual office there, you’ve got the U.S., you’ve got Canada, you’ve got South America.

    Oh, and you know what? Actually, I was just gonna say we’re not in Africa—we’re totally in Africa, so it’s everywhere. And then even, we’re not in the Middle East, I don’t think. But even more interesting, I think, than where the people are, it’s where the data centers are. You’ve got this crazy Cartesian product of people trying to connect to stuff, and most companies—we’re in China, I mean, we’ve got people on, we have workers on factory floors in China who need to SSH into infrastructure.

    Shimel: Very cool.

    Zalman: And so, it’s crazy to think about all of the networking going on, the latency, and how to make that connect, and it’s just personally fascinating to hear the new use cases that come up. I was like, when I heard factory, I was like, “Wow!” And then I started thinking of, like, Tesla. I was like, “I wanna be on the factory of Tesla,” but no.

    Shimel: Yeah. That could be in China, too. You know, it’s funny you bring it up, I actually interviewed a CEO of a company maybe last week who, they are instrumenting manufacturing factories, because a lot of that machinery was not connected that you can, you know, you had visibility, and they actually put things on to machinery that allow you to instrument them and monitor and stuff. There’s amazing things going on. And by the way, each one of those add-ons to the manufacturing machines has to have a certificate, an identity—you know, there’s a whole piece of this, too, and I just think it continues to go on.

    Steve, we don’t have a lot of time left. How has the COVID thing kinda affected you guys?

    Flinchbaugh: So, personally, I feel incredibly fortunate to say that my work has changed almost not at all. I think my position and a lot of our department is very remote friendly, and even though we weren’t set up, really at all, for remote before the pandemic, the transition has been relatively seamless—obviously, from a strongDM perspective, it is seamless.

    But overall as a company, I think—of course, there’s a ton of adjustments with different departments and some are having it easier than others. But I actually think engineering is, our efficiency and output and how we’ve put out features since the beginning of this has actually increased just a little bit.

    Shimel: That’s great to hear, man. Really good. Guys, we’re about out of time. I want to thank both of you—both of you coming at us from New York, today, I should mention, so thanks for joining us. Liz, any last thoughts, comments you want to add?

    Zalman: Nope, I don’t think so. I wanted to say thanks to Steve, and I appreciate the comment on relationship. It’s so important, as I say—you know, at strongDM, everybody touches the customer equally. It doesn’t matter if you’re in account management or support or engineering that I joke that if we were to ever have commissions at the company, which we don’t, I would give support the commissions, because they’re that important.

    Flinchbaugh: As a support company, somewhat as an employee there, I can very much appreciate your support team as well, Liz, and it’s not an exaggeration to say it’s the best support that I’ve received from any vendor, ever.

    Shimel: Very cool, very cool. That’s a good way to end it. Alright, Elizabeth Zalman, CEO, strongDM; Steve Flinchbaugh, SRE at Kustomer with a K—thanks for joining us on TechStrong TV. This is Alan Shimel. We’ll be right back with our next guest.

  • Shifting Left With DevSecOps: ESG Report Exposes Difficulties

    Shifting Left With DevSecOps: ESG Report Exposes Difficulties

    A recent report asks the tough questions about DevSecOps adoption, and the results are surprising

    In a world of increasing development velocity, companies are placing more responsibility on developers to enact quick deployments. Naturally, security is “shifting left” as well.

    Theoretically, DevSecOps sounds great, but it opens up many questions. Who exactly is responsible for security knowledge? Are cybersecurity training measures effective? Which tools excel at decreasing risk while maintaining release fluidity? Are AppSec tools aiding or adding unneeded friction?

    A report conducted by Enterprise Strategy Group (ESG) sought to answer these pressing questions and expose trends around application development security. The study surveyed 378 IT, cybersecurity and application development professionals at organizations in North America.

    I recently met with Chris Eng, chief research officer at Veracode, and Dave Gruber, senior cybersecurity analyst at ESG, to dig deeper into the report’s findings.

    Security vs. Development

    There is still friction when attempting DevSecOps in practice. Eng recognizes a disconnect between security and development teams.

    “Most security teams lack an understanding of modern application development practices,” said Eng. Security may not realize how regularly code is pushed or understand the intricacies of tooling within a CI/CD pipeline. On the flip side, developers may not be well-versed in common container exploits and vulnerabilities.

    Organizations are pretty split when it comes to application security testing ownership. Thirty-one percent of organizations dedicate security analysts to manage application security. The development manager and security team jointly own responsibility at 29% of companies. Developer managers follow at 26%, and individual developers at 13%.

    To Eng, these figures reflect an evolution from traditional security testing to the way things are changing with faster development cycles. “Go back 10-plus years, and we had a centralized, dedicated security team responsible for managing AppSec,” described Eng.

    In modern times, security is shared or even furthered where developers themselves run tools by hand or automate security within CI/CD processes. Large companies, Eng noted, now often utilize a mix of those practices.

    Paradox: Secure Yet Vulnerable

    Seemingly, the most eye-opening part of the report was a paradox. The report found that most teams give their application security a high rating (36% gave their application security programs a 9 or 10, with a 7.92 mean). Yet, the majority say they regularly push vulnerable code (48% of respondents knowingly push vulnerable code regularly).

    Though it’s counterintuitive, organizations may knowingly push out vulnerable code for many reasons. “You’ve promised a release, customers are waiting, ” said Eng. “Revenue is waiting. What are the implications of pushing that release?” Teams may not have time to fix vulnerable code, or it may simply not be worth it.

    Publishing vulnerable code may also be a symptom of placing testing too late in the release process. “That’s why there is this trend to shift left,” added Gruber.

    Gauging DevSecOps Success

    The above findings underscore a reality of IT security: To keep pace, software providers must accept a level of risk. In fact, business success may depend on it.

    “The effectiveness of the programs isn’t necessarily measured with how many times you’ve shipped your code with no vulnerabilities,” said Gruber. “Success is that we understand the risk, we have mitigated the risk at the level we believe is right for the organization, and have the right level of control over the process.”

    Companies must weigh the cost of improper DevSecOps and mitigate imminent risk to maintain release agility.

    Application Security Tools: Finding Balance

    At modern companies with quick-release cadences, “CI integrative security tools are way more prevalent and baked into the process,” noted Eng. Yet, 26% of respondents indicate security tooling friction and ineffective tooling usage.

    Whereas InfoSec teams are usually the ones dictating policies, developers have much influence in the tooling selection. Thus, tools must appeal to the developer experience, fitting into their established workflows.

    “We have to build a habit around it,” said Eng. Frictionless tools that continually scan within an IDE, for example, can enable developers to fix an issue on the spot and foster future behaviors.

    At the same time, you must set standards and avoid governance issues. This requires control and observability. “The balance here is that you want developers to be able to integrate something tightly into their toolchain,” said Eng. “But InfoSec needs a bird’s eye view on the organization.”

    Developers Lack Knowledge to Mitigate Issues

    Though security tools may reveal vulnerabilities, they don’t always correlate with remediation. The ESG report found 29% of developers lack the knowledge to mitigate issues identified by security tools.

    There is a clear gap in the market when it comes to developer education around security. This could stem from computer science schooling, in which cybersecurity is rarely taught alongside programming languages.

    On the job, hands-on developer security training is also spotty. Thirty-five percent say that less than half of their development teams are participating in formal training. Only 15% of organizations have developers actively involved in security training.

    Just giving developers a laundry list of vulnerabilities doesn’t help mitigation. For Eng, what organizations require is habitual, recurring training with hands-on tools. “Try to simulate or provide a real-world environment for learning, identifying and patching these issues,” recommended Eng. Integrating tooling within the daily developer workflow can help with knowledge retention, because “if you don’t use it, you lose it.”

    Other best practices will only arise with a security habit. For example, most development environments ship with open defaults. “You need security training and tools to understand to restrict that appropriately,” noted Eng.

    That said, a wide variety of security tooling is already advancing this process. For example, 56% of organizations use API security vulnerability (ASV) scanning to identify and mitigate risk associated with API usage, helping secure applications as developers code dependencies.

    Final DevSecOps Thoughts

    The ESG study found 43% of participants believe DevOps integration is most important to improving AppSec programs. Yet, siloed roles and a lack of security education mean DevSecOps must still mature quite a bit to meet the security-shift-left vision.

    Other eye-opening findings included:

    • More than half of respondents (54%) use automated controls to identify and quarantine vulnerable images in their image repository.
    • The proliferation of AppSec tools on the market is a significant problem for 30% of companies.
    • AppSec spending is increasing, yet only 30% will protect more than three-quarters of their codebase 12 months from now.

    For more findings, check out the ESG Survey Report: Modern Application Development Security.

  • Progress Acquires Chef to Expand DevOps Portfolio

    Progress Acquires Chef to Expand DevOps Portfolio

    Progress today announced it has acquired Chef for $220 million in cash as part of an effort to advance adoption of best DevOps and DevSecOps practices in the midmarket.

    Once the deal is completed next month, Chef will operate as an independent business unit led by Sundar Subramanian, who currently is a senior vice president and general manager at Progress.

    Progress CEO Yogesh Gupta said IT automation technologies developed by Chef will be incorporated into monitoring and debugging platforms and tools that Progress currently provides. By moving into areas such as compliance and security, Chef has already embarked on an effort to make its offerings more accessible to IT personnel, who often lack programming skills, especially in midmarket IT organizations that make up the bulk of the Progress customer base.

    As a private company owned by venture capitalists who monetized open source software mainly via commercial support agreements and enterprise editions of its software, Chef has been able to generate roughly $70 million in revenue. As an arm of Progress, Chef joins a public company with more than $500 million in revenue that has a market capital in excess of $2 billion.

    Chef should be in a better financial position to compete against rivals such as Puppet and Red Hat. Following its acquisition by IBM, Red Hat has been plowing consider resources into a declarative Ansible automation framework that tends to appeal to traditional IT teams. In comparison, Chef has been a pioneer in automating IT using programming tools that especially appeal to DevOps teams managing infrastructure as code.

    In general, most midmarket IT organizations don’t have a lot of DevOps expertise. As an independent arm of Progress, Chef will continue to focus on IT operations, compliance and security, while Progress focuses more of its efforts on the application development and deployment requirements of midmarket organizations, said Gupta. As midmarket IT environments become more complex, the number of touchpoints between Progress and Chef involving cookbooks and recipes created by Chef will increase over time, he added.

    The acquisition of Chef is the latest in a wave of consolidation across the DevOps category. While adoption of DevOps tools and platform continues to grow, traditional enterprise IT organizations are now moving to acquire many of the larger vendors in the DevOps category. That trend is only likely to accelerate during an economic downturn brought on by the COVID-19 pandemic. At the same time, the number of startup companies being launched continues to expand the overall size of the DevOps/DevSecOps ecosystem.

    It’s too early to say at what rate best DevOps practices will gain further traction among traditional midmarket IT organizations. However, at a time when many of those organizations are being asked to do a lot more with even less, it’s only a matter of time before existing rigid IT processes begin to incorporate more agile approaches to managing IT as a matter of survival.

  • Fastly Sets DevSecOps Strategy After Signal Sciences Buy

    Fastly Sets DevSecOps Strategy After Signal Sciences Buy

    In the wake of acquiring Signal Sciences for $770 million, Fastly is gearing up to expand the range of security services it offers as part of an effort to advance adoption of best DevSecOps practices.

    Artur Bergman, chief architect for Fastly, said a forthcoming wave of edge computing applications will require web applications firewalls (WAF) that can be deployed and managed remotely to protect them. As a provider of a content delivery network (CDN), Fastly will leverage the WAF platform developed by Signal Sciences to secure edge computing platforms within a forthcoming Secure@Edge service that promises to unified web application and application programming interface (API) security.

    Fastly has been gaining ground as a provider of CDN services that are programmatically designed from the ground up to shift control over networking and security services further left toward DevOps teams, said Bergman. In many cases, the only way to secure workloads running on an edge computing platform is for DevOps teams to be able to programmatically deploy a WAF to protect the workloads on that platform, he noted.

    Edge computing platforms are especially vulnerable to distributed denial of service (DDoS) attacks that are increasing in both size and sophistication as cybercriminals become more adept at targeting specific servers and platform, added Bergman. No one can prevent a DDoS attack from being launched, but a CDN can play a critical role in mitigating its impact.

    The acquisition of Signal Sciences comes on the heels of Fastly’s move to expand its the ability to collect metrics from edge computing platforms that will be employed to extend the reach of monitoring tools employed by DevOps teams to edge computing platforms.

    Zane Lackey, chief security officer for Signal Sciences, said the two companies share a similar history and commitment to best DevOps practices. The WAF from Signal Sciences is based on a runtime application self-protection (RASP) architecture that only runs when an application fires up, which Lackey said makes it a natural extension of any DevOps toolchain.

    The Signal Sciences WAF is unique in that it can support multiple classes of monolithic and microservices-based applications and that 95% of organizations that employ it do so in full blocking mode because the number of false positives the WAF generates is limited, added Lackey.

    Naturally, Fastly is not the only provider of a CDN services looking to woo DevOps teams. Organizations have been deploying web-based applications on CDNs for years. However, CDNs that simplify the deployment of applications within the context of a DevOps workflow are gaining traction.

    It’s too early to say how this battle will play out. In addition to providers who have built their own global networks, cloud services providers also now offer CDNs that promise to optimize cloud application performance while enhancing security and simplifying deployment. Regardless of the path forward, it’s clear that as more latency-sensitive applications are deployed across distributed computing environments, the more inclined DevOps teams will be to rely on external network services that can adapt quickly to changing application requirements.

  • DeepFactor Unifies Performance and Security Monitoring for Developers

    DeepFactor Unifies Performance and Security Monitoring for Developers

    DeepFactor today launched what it describes as the first continuous monitoring platform designed specifically for pre-production environments.

    Company CEO Kiran Kamity said the DeepFactor Pre-Production Monitoring platform combines security, performance and behavior monitoring in one offering. Based on a “Deep Passive Monitoring” capability that requires developers to add a file to a container image to instrument an application, the platform feeds the telemetry data collected via that file to an Application Runtime Intelligence engine. That engine surfaces potential security and performance issues as well as risky and unexpected behavior changes between versions of applications, he said.

    Scans of application environments are launched via a DeepFactor portal. Each scan is then compared to a set of configurable rules that are developed and maintained by the DeepFactor research team to identify indicators of application misbehavior. The engine also learns the application environment, which over time enables DeepFactor to generate alerts based on threshold triggers, known bad behaviors, anomaly detection and other attributes.

    The DeepFactor Pre-Production Monitoring platform also comes with pre-packaged integrations for widely employed DevOps tools including Jira, Jenkins, Slack and GitHub.

    In addition to the commercial platform, DevOps teams can also make use of a DeepFactor Standard Edition, which is free for non-commercial open source projects with no user limitations.

    In an ideal world, developers would address issues, including security, long before an application is deployed to a production environment. The issue is that developers are asked to navigate too many tools to achieve that goal. The DeepFactor Pre-Production Monitoring platform will make it easier for developers to surface insights in a frictionless way, said Kamity.

    Most organizations that embrace best DevOps practices embrace observability as a core tenet. The challenge they face is making it easy for developers to instrument applications as they are built and then making sense of all the telemetry data collected. That’s especially critical as developers attempt to strike a balance between remediating security issues and optimizing performance to better ensure the overall user experience. Existing developer tools are optimized for performance; asking developers to switch tools to address potential cybersecurity issues is a task that can be delayed to the point where it is essentially forgotten or simply ignored.

    It’s not clear to what degree DevOps teams might have the budget dollars required to deploy their own monitoring tools versus relying on the existing monitoring tools provided deployed by an IT operations team. However, it does usually take a significant amount of time to deploy and update the agent software that legacy IT monitoring platforms require. DeepFactor is making the case for capturing telemetry data using a comparatively lightweight container that can be added to either a monolithic or microservices-based application.

    Of course, if an application is already instrumented in a pre-production environment it might make sense to use the same monitoring platform to observe applications in a production environment. However, convincing IT operations teams to swap out their existing monitoring tools for something that makes the lives of developers easier might be a tall order.

  • Security Compass Unveils DevSecOps Platform

    Security Compass Unveils DevSecOps Platform

    Security Compass today launched a DevSecOps platform that guides developers toward building secure applications faster using a set of security analysis tools and processes embedded within it.

    Company CEO Rohit Sethi said SD Elements is the first instance of what the company is positioning as a balanced development automation (BDA) platform. By defining a set of best practices for building secure applications, organizations can strike a better balance between building applications fast and ensuring those applications are secure and compliant with any number of regulatory requirements.

    Too much of the focus on application development is on pure speed, said Sethi. SD Elements is designed to offer a more structured approach that provides developers with access to threat modeling and risk assessment tools to reduce the number of vulnerabilities finding their way into an application.

    SD Elements first gathers details such as the technology stack, deployment environment and compliance requirements. It then classifies risks based on security and compliance policies defined by the organization, which are then employed to surface recommendations to the developer. SD Elements also automatically tracks the status of security activities via integrations with security testing tools such as Veracode, Checkmarx or Fortify to generate reports that identify risks and current mitigation status.

    Finally, SD Elements provides access to a library of thousands of security and compliance recommendations and controls, including code samples and test cases, that are mapped to regulatory and compliance standards from all over the world.

    To some degree DevSecOps will slow down the rate at which applications are developed. Security Compass, via BDA, is making a case for minimizing the impact security gates will have on the rate at which applications are developed. It’s not clear BDA as a market category will catch on, but as providers of DevOps platforms continue to embed security tools in their platforms the entire category is evolving.

    The challenge many organizations face today is they want developers to embrace DevSecOps as part of an effort to shift responsibility for application security to the left. However, organizations are still working to put the tools and processes in place that would enable developers to achieve that goal. Most developers want to build and deploy secure applications; this needs to occur within the context of a structured approach that has a foundation in best DevOps practices.

    Each organization will need to determine to what degree they may need to slow down application development to build more secure applications. In theory, the smaller the workloads the easier it is to secure them while continuing to rapidly iterate. However, that level of DevSecOps maturity takes time and effort to achieve.

    In the meantime, it’s clear DevSecOps has become a requirement as part of an overall effort to better secure the software supply chain on which so many organizations now depend. The challenge is finding a way to adopt DevSecOps in ways that developers will embrace rather than resist.