Tag: devsecops

  • GitHub Delivers on Code Scanning Promise

    GitHub Delivers on Code Scanning Promise

    GitHub today announced it is now making available at no cost the open source CodeQL code scanning tool it gained by acquiring Semmle.

    Justin Hutchings, a product manager at GitHub, said the goal is to further adoption of best DevSecOps practices by making it easy for developers to scan for vulnerabilities as they check code in and out of the GitHub repository. It is also designed to be integrated with either GitHub Actions or an existing continuous integration/continuous delivery (CI/CD) platform to enable DevOps teams to create workflows that include code scans, he said.

    For private repositories, code scanning is part of the GitHub Advanced Security suite of tools GitHub makes available via GitHub Enterprise.

    Code scanning also makes it possible to integrate third-party scanning engines via support for the Static Analysis Results Interchange Format (SARIF), which provides a standard for sharing data between SAST tools via a common application programming interface (API). GitHub has thus far partnered with more than a dozen open source and commercial security vendors to allow developers to run code scanning within their offerings, noted Hutchings.

    GitHub claims since it made CodeQL available in beta last May, it has scanned more than 12,000 repositories more than 1.4 million times and found more than 20,000 security issues involving everything from remote code execution (RCE) and SQL injection to cross-site scripting (XSS) vulnerabilities.

    Developers and maintainers fixed 72% of reported security errors identified in their pull requests before merging in the last 30 days alone, reported GitHub. Hutchings noted those efforts represent a major step forward for DevSecOps, given the fact that industry data shows that less than 30% of all flaws are fixed one month after discovery.

    GitHub, along with the open source CodeQL community, has also created more than 2,000 CodeQL queries that DevSecOps teams can employ to scan code for specific types of vulnerabilities. GitHub also noted there already have been 132 community contributions to the CodeQL open source query set.

    Given how nascent best DevSecOps practices are in most organizations, simply making SAST tools available to developers is often a major step forward for many organizations. The challenge has been finding SAST tools that developers want to employ, said Hutchings. Most SAST tools were designed for security teams rather than developers. CodeQL is designed to surface vulnerabilities in a way that makes it clear where developers need to prioritize their remediation efforts, he noted.

    It’s not clear yet to what degree responsibility for security will shift left toward developers. There will always be a need for cybersecurity teams to verify that the proper controls are in place. However, as DevOps teams assume responsibility for security it’s almost certain they will do so on their own terms. The days when cybersecurity teams select the security tools that developers are expected to employ are now all but over.

  • TechStrong TV: strongDM With Betterment

    TechStrong TV: strongDM With Betterment

    Betterment is a goal-based financial advisory company that provides robo-advising services to help customers make the most of their money, taking away all the complexities of investing and saving.

    In this interview for TechStrong TV, strongDM co-founder and CEO Elizabeth Zalman and Chris Becker, SRE manager at Betterment, joined us to discuss how strongDM helps make things faster, automated and easy at Betterment by tracking and auditing all changes on their system.

    Chris was the project lead for implementing strongDM at Betterment. During this segment, Chris shared his journey of becoming manager of the SRE team at Betterment and the reasons why they chose strongDM to secure access to their data.

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

    Transcript

    Alan Shimel: Hey, everyone. We’re back here at TechStrong TV, and for our next segment. For this segment, we have one of our semi-regulars back here, Liz Zalman of strongDM. Hi, Liz—how are you?

    Elizabeth Zalman: Hi, Alan. I’m well, thank you.

    Shimel: Good, thanks for joining us. And joining Liz and I today is Christopher Becker, SRE with Betterment. Is that correct, Chris?

    Chris Becker: Yep, SRE manager at Betterment.

    Shimel: Very cool. So, Chris, you know, I got a little background on Betterment before we started recording today, but why don’t you share with our audience—what’s Betterment? What do you guys do?

    Becker: So, yeah, the elevator pitch for us is that we’re a robo-advising platform that helps you make the most of your money. So, the idea with us is, we take away all the complexities of investing and saving and we’ve turned it into a goal based platform that lets you invest your money, save for what you’re going for, and try and make the most on top of the market and everything like that.

    So, we—yeah, we try and take all the trouble of saving and all that, we dynamically balance portfolios and things like that for you and, as Liz said, it kinda removes all the distracting stuff with money.

    Shimel: Very cool. And, you know, what’d kinda unique about it is, it’s very goal based, right? So, you gotta tell Betterment what are your goals, what are you saving for, here? I wanna buy a house, I wanna buy a car, I wanna put money away for retirement.

    Becker: Mm-hmm.

    Shimel: I wanna go on—I wanna take 180 days off and cruise around the world. That would be mine, but anyway. [Laughter]

    Zalman: [Laughter]

    Shimel: You know, so, it’s a pretty unique kind of thing like that, and it’s—I guess it’s kinda uniquely situated for, I’m gonna assume, a lot of your customer base is sorta Millennial, Gen Z kinda folks, or do you get, you know, old people like me?

    Becker: [Laughter] We have everyone, all over the gamut. I think—yeah, like, you mentioned the goal based investing, and that’s what’s super important to us. And it helps us sort of like—it helps us make the calculations about how we balance everything.

    Me, for instance, I have a goal that’s like saving for a house, and that’s a much different trajectory than something like retirement for me, based on my age and my income and everything like that. And what Betterment helps you do is just save in the best way to hit those goals. So, if you’re trying to get X amount of dollars by Y date, there’s sort of a formula that does that, and if you’re saving for retirement, there’s a different formula that works with that. It’s all kind of within our platform.

    Shimel: Cool. So—and, of course, the website, let’s get that out of the way, B-E-T-T-E-R-M-E-N-T dot com?

    Becker: You got it.

    Shimel: Okay.

    Zalman: And there’s a mobile app.

    Becker: And there’s a mobile app. [Laughter]

    Shimel: [Laughter] There’s an app. And we should also—hey, full disclosure, Liz has told me not only is Betterment a customer of strongDM but Liz is a customer of Betterment, so.

    Becker: [Laughter] Exactly.

    Zalman: It’s a great product. [Laughter]

    Shimel: Take it with a grain of salt—take it with a grain of salt. [Laughter] Anyway, Chris, let’s talk a little bit about your background, though, now. So, you are manager SRE there, and our audience is very, very familiar with SRE and SREs in general. But how does one become a manager of the SRE team?

    Becker: Absolutely. My background is particularly interesting. I guess, rewinding the clock a little bit, I was—I got into sort of computers and computer management and server stuff, like, way back in high school. I come from a pretty, I guess you could say, classical IT background. I actually have, like, a Microsoft MCP, if you can believe that, like, from back in the day.

    Shimel: I do.

    Becker: [Laughter] Yeah, Server 2003 Active Directory, so.

    Shimel: Mm-hmm.

    Becker: That’s—yeah, I went to a high school with a really great computer program that let a lot of the students get hands on access to stuff, and by my sophomore year, me and my other classmates were sort of managing our computer labs and learning about how to do all that kinda stuff.

    So, that’s like—yeah, I guess I was fortunate in that I got into this really early and it was something that I was really excited about and I was kind of like, you know, that guy in high school with my buddies, we built computers and things like that as well.

    But yeah, and then right out of high school, I went to college and studied Information Technology as well. And one of the things that, like, for me, I’ve always sort of been, I guess, the jack of all trades when it comes to technology—everything server management, a little programming, and things like that. And then out of college, I actually got a job at Warby Parker doing office support, so like, IT support.

    And that’s kind of, for me, where, I guess you could say the automation bug, I got bit by that. Because we were doing a lot of software installations and things like that on people’s machines and we wanted a way to, like, with our two person IT team scale out to support, like, you know, 300 people at Warby at the time.

    So, it was like investigating, you know, more things that we use in the SRE world today, like, things like Ansible and things like automation scripts and stuff like that. I was kind of, like, getting introduced to that as a way to just make it so that our small team could manage and automate installations on a bunch of work stations.

    And then from there, actually, within Warby Parker, I had the opportunity to change to what they called an infrastructure engineer role which, looking back on it now, it was essentially, like, DevOps, right? You know, because DevOps is, I guess, the big umbrella that covers a lot of different disciplines and stuff like that.

    So, from there, I really—I leveled up a lot of my programming skills as well, writing automation scripts and stuff to set up developer work stations. But what was important, I think, in that role for me is that I had a really good relationship with sort of internal customers, as I like to call them, for my IT role where my sort of stakeholders of the things that I built weren’t people that were the traditional customers of the business but rather those that, people that worked or the business.

    So, I think a lot of—like, one of the reasons why I like DevOps and SRE and things like that is because it allows you to have a really close relationship with your customers, because they’re in the same company as you are a lot of the time, so.

    And yeah—and then after Warby Parker, I got a job as an SRE at Betterment and our team was similarly very small. There was, I think when I started, there was four of us and we were supporting an engineering organization of around 80 folks and then, from there, our engineering team grew as well as our SRE team. And now, I’m the manager of that team and so, having been on that team for two years and change before becoming the manager, I had a really good sense of what we liked to do, things we wanted to build or our engineers and platform things as well. So, now, I’m kind of like at the helm and get to control that, which is really, really cool.

    Shimel: Excellent, man. Great story. You know what, Chris, I don’t think your journey is that unusual, to tell you the truth. I mean, I spend my life talking to people like you and Liz and—I mean, what’s different is, you know what, my high school didn’t have a computer lab, my college had punch cards. But, you know, my children, for instance, our local high school here in West Boca Community High, they actually do have, they have actually a Microsoft Certified program. So, a lot of—you know, you become Office certified, big deal, as a freshman. But by the time you graduate, you are Microsoft Certified.

    They might have, I don’t know if they’ve moved over to Google stuff now and more cloud-based kinda things, but there’s a cyber security area of concentration they call it, which is pretty cool, too. And, you know, it’s good. I mean, because so many people of my generation who—look, we took the Internet commercial, right, and built what you see here. But so many of them are self-taught, especially in things like DevOps or cyber or, you know, those kinds of things. And so, it’s good to hear people with real academic backgrounds in this stuff. I think it bodes well for the future.

    But, you know, part of what you guys are doing, obviously, is, you called it infrastructure engineering or at Warby Parker, DevOps. But the real thing here is that we’ve moved, in your lifetime, right, in your career—I don’t know if they ever had the concept of the server closet and the data center on prem. Everything is SaaSOps, right, or cloud or some sort of hybrid of that, right? There might be some third party data center you use where you’re running, let’s say, a private cloud kinda thing. You mentioned Ansible—well, that was back at Warby, so I don’t know if you’re using OpenShift or anything like that.

    But clearly, right, it’s not—this is today’s infrastructure, today’s kinda new stack as I like to call it. What about Kubernetes, cloud native, any of that stuff?

    Becker: Yeah. So, that’s like, at Betterment, we’re using Kubernetes. We’re on top of AWS as well. And I think it’s—I like that you mentioned sort of like old server clouds and stuff. I think the last time I interacted with a physical rack server was probably in college. But, I mean, I grew up punching Ethernet cables and racking and stacking and configuring, you know, Ratarays and things like that. And I think what—

    Shimel: Fun times. [Laughter]

    Becker: Yeah, right? [Laughter] Well, not with Ratarays, but I think—yeah, what I really like about sort of my, I think where my background has been really helpful for me is like, you know, when you enter this new world of AWS and cloud configurations and Kubernetes and stuff like that, like, it’s all still based on the fundamentals. And I feel like I got a really good sense of, and a really good education in networking fundamentals and things like that. Which, if you look under the hood, Kubernetes abstracts a lot away from you, but you still might have to do some kind of site or notation calculations, right? Or figure out, like, some [Cross talk]—

    Shimel: It’s been a long time since did CIDR.

    Becker: [Laughter] And it’s—and things like, yeah, and figuring out, like, we were debugging an issue with network connections and being able to Wireshark and look at the TCP handshake and figure out why we were dropping packets or getting RSTs or something like that. Like, being able to sort of zoom into those things that we don’t necessarily think about a lot these days when we sort of turn on a server in AWS and we don’t really think about—like, being able to sort of lean on that knowledge is incredibly helpful in those head scratching debugging moments and stuff like that.

    Shimel: Yeah. No, no, it’s always good to understand what the underlying technology is about. But part of what—and this is really something strongDM does, right? Part of what we’re doing here is, we want to make it chimp simple. We want it to be fast, automated, easy. That’s a big part of the SRE kinda mantra as well, right?

    Becker: Yeah.

    Shimel: And so, let’s talk a little bit about strongDM over at Betterment, right? How did—was it there when you got there? It sounds like you’ve kinda built the thing, though, you brought it in. Talk to us about the use case, here. What made you go with strongDM, why, what problem were you trying to itch, here—or, yeah, what scratch were you trying to itch?

    Becker: Absolutely. Yeah, no, for us—so, I was actually the Project Lead for implementing strongDM at Betterment. So, I absolutely love it, first of all. It’s one of my favorite apps because I don’t have to think about it ever, and that’s like—if I forget, like, it’s something so seamless and it is so well run that I forget about it, those are my favorite kind of pieces of software. [Laughter]

    Shimel: Well, no, that goes to what we just said. We wanna make it that simple, man.

    Becker: Easy, simple, automated.

    Shimel: I don’t wanna do CIDR calculations.

    Becker: [Laughter]

    Shimel: [Cross talk] [Laughter]

    Becker: Yeah, no—so, for us, we had a need at Betterment, obviously, we’re a financial institution, we have regulations that we abide by and these things, one of these things is auditability and we need to make sure that any changes to any systems that we have and that we run and we operate are auditable, it’s tracked, it’s logged.

    So, for us, strongDM was sort of like the perfect picture, because it allowed us to use that platform to get auditability, we could track and log everything as well as push everything with SSH at the time through one system, which was really nice. And it also had the added goal of not being dependent on our VPN, which we’re trying to get rid of as well, for a lot of reasons. [Laughter] strongDM, yeah, allowed us…

    And also, the thing that I’ve said amongst my team and one of the reasons why I really like strongDM is, it sort of abides by what I like to call the Unix philosophy, right? Like, it does one thing and it does it well. And it’s very predictable in its command line, it’s very predictable in the way that—its interface and it interacts with other servers and things like that. And it was really easy for us to build out this entire system with, you know, literally running two EC2 instances and they’re able to get into hundreds and hundreds of servers every day and have never had an issue, so.

    Shimel: So, Liz, five interviews—this is the longest I’ve ever heard you go without speaking. What’s up? What can you tell us about this?

    Zalman: What I can tell you is that Betterment, I think, is, I’m gonna say top three in terms of forward thinking customers that we have. They’ve pushed the envelope in a variety of ways. They were using SSH, I think, where they had requirements for how they wanted engineers to interact with SSH that we didn’t yet support in the platform. I think the same thing went for kubectl as well or usage of Kubernetes. They were the first to really stress our system—not stress our system in terms of, like, we went down, but stress in terms of, “I wanna automate stuff like this, and you’re doing this, and I need you to get to this.”

    I can’t count the number of times that Chris asked for a REST API. Have you used it yet, by the way?

    Becker: [Laughter]

    Shimel: Tell the truth, have you?

    Zalman: Have you used it yet?

    Becker: Oh, yeah—no, we have. Yeah, we used it.

    Zalman: Okay—good, good, good. [Laughter]

    Becker: Yeah.

    Zalman: They had requirements in terms of directory syncing—yeah, so, it was a pleasure to work with them. And I actually don’t recall—did we meet when you were at Warby, or were you just sort of aware of that relationship?

    Becker: You actually, I think you came in to meet the infrastructure team, like, the Ops team at Warby at one point.

    Zalman: Yeah.

    Becker: Because I remember we were piloting strongDM at one point. I don’t think I was there when the implementation happened or anything like that.

    Zalman: Oh, yeah.

    Becker: But I was familiar with the product from Warby, actually.

    Zalman: Yeah. And Alan, it’s actually interesting—Chris is part of a, Chris used to be based in New York City and in New York, there is this group of infrastructure folks that stays within sort of the B2C world in my opinion and goes to the unicorns. And it was almost borne out of Warby, some went to, like, Harry’s for shaving, some went to Peloton, some went to Betterment—I’m sure I’m missing a couple companies. And they’re almost more forward thinking than our traditional B2B clients are. It’s a very interesting trend.

    Shimel: Yeah. You know, one of my good friends is a guy named Brad Feld out of Boulder, and Brad, he founded TechStars and Foundry Group. He used to be—he’s a big VC. But he’s also an author and he’s written this whole series around what they call startup communities, and it really talks about, Liz, what you were just saying, right? Generally, you get a pool of talent, right, in a geographic region—within a community; it doesn’t have to be geographic, actually, but within a community. And that talent, it’s almost like the six degrees of separation, right? You can see a company has a liquidity event, people make money and they start other companies. Or they develop some really great expertise—in this case, kinda B2C, using real edgy kind of…I gotta stop using the word edgy, because it’s now meaning The Edge. But, you know, kind of cutting edge is what I mean—technology players.

    And they do, that—you can almost trace the DNA, if you will, right, from company to company to company because it’s that same, the same roots of people. And that’s what makes a startup community, because along the way, right, more people get added into the tribe, if you will, right? And that tribe continues to grow. And that’s how—I mean, that’s how tech centers are born, right? You can trace—like Boulder, for instance; Boulder, Colorado—you can trace a lot of what came out of, what’s coming out of Boulder by from when the storage folks were there and IBM had a big facility there and the University of Colorado and Brad coming in and investing a lot of money. There were a handful of companies that had really great outcomes or liquidity events, and it gave rise to this whole—Austin the same way, I mean, by the way.

    Anyway—strongDM. So, Chris, what are you guys using it for? Liz mentioned some REST APIs and stuff like that, but how—what are you using it for, how is it working out, what do you see?

    Becker: Yeah, so, we’re using it for, our sort of highest level use case is any time a developer needs to access a server or a database or a cluster, a Kubernetes cluster that we run and operate, they go through strongDM. And for us, like I said before, that was super important, because we want to make sure that all of the changes to our systems are tracked and audited.

    So, we have—we actually started out just implementing sort of the SSH back end, and like Liz alluded to, we had some very interesting requirements around directory services. So, we use Okta as our identity provider and directory service.

    Shimel: Sure.

    Becker: And strongDM helped us wire that together so that a person on the team, their e-mail address and their Okta identity is used by strongDM so that we can sort of tie all those things together.

    We also had, like, another thing that Liz alluded to was sort of like, we had a ton of servers and one of our unique use cases was, at the time, we were heavily using autoscaling groups within AWS. So, one of the big things with us and strongDM was that the server inventory was extremely dynamic, depending on load of our servers, depending on deployments and things like that. We might have 100 servers in inventory, we might have 200 servers. And they were coming up and down sort of all day.

    So, for us, one of the other interesting requirements is, we needed some kind of automation so that when an AWS would turn on a new server to handle extra server load that that server was automatically enrolled and registered in the strongDM platform.

    So, yeah, again, we worked with strong a lot on sort of nailing down that interface and we’ve written some automation scripts and things like that to get it to register and everything like that, and their admin, their admin token API and everything like that made that a breeze. And then our most recent implementation is actually, we use strongDM for Kubernetes. So, we basically have a, when you need to get access to our Kubernetes cluster or debug an application in our cluster, we actually live provision a container and then your proxy through strong, like, right into that container and all of that is audited as well.

    And all of our developers, actually, they don’t even—the best part is, they don’t even understand, like, they can connect to an old system or a new system and for them, it’s completely transparent. But yeah, it all runs through strong and it all is—and for our compliance reasons, that’s all audited and tracked and logged, which is great.

    Shimel: That’s nice. Two things I wanna highlight here and then Liz, I’m gonna ask you to expand on it. Number one is that, by using strong, what Chris’ team is able to do, as he mentioned, they use Okta—they don’t have to worry about hooking up this person’s identity maybe via e-mail with their Okta identity for purposes of IAM, right, across their disparate network infrastructure, right?

    strongDM here, as part of the proxy process, is lining up that person’s real identity, right, their e-mail or whatever you wanna use as their real identity with their IAM identity—I call it an IAM because it could be Okta it could be others, right? And then—but the person doesn’t have to think about that, and quite frankly, Chris, neither do you or your team, right? strongDM just makes that—again, chimp simple, easy, done.

    Becker: Yep.

    Shimel: That’s number one. Number two—and Liz, this is where I really, I’d like you to comment in—the idea of using it in this Kubernetes system and containers, as Chris is referring to, is that the norm now, or do you think this is kind of an advanced use case?

    Zalman: It’s an interesting question. And yeah, I think to your first point, it’s, we’re acting as an infrastructure API, right? We don’t care what Chris is using as his identity store. We don’t care where his infrastructure is, we’re just connecting the dots.

    Shimel: Yep.

    Zalman: Kubernetes was—I mean, we’ve seen different instantiations of Kubernetes over the years, right? Docker tried with Swarm and it didn’t stick and Kubernetes did. And maybe people were using it, they were trying it on. And I remember, like, the month that it hit production workloads, because I think we got seven or eight requests in one week. It’s like—why don’t you have support for this protocol? And we said, “Okay, time to build kubecl support.”

    Shimel: Time to do that, yeah.

    Zalman: Yeah.

    Becker: Yeah, guilty. [Laughter]

    Zalman: Yeah, you were one of them. [Laughter] It was like plain, plain, plain, plain, plain—mainstream. And so, I think everybody is trying to find some way to systematize and puppeteer everything that’s going on and abstract away a lot of complexity.

    So, no, to me, Kubernetes is certainly here to stay. I see everybody using it.

    Shimel: But is their—because it sounds like their Kubernetes installation, if you will, the way they’re using strongDM is maybe a little different than—is that the standard way that people are using strongDM and Kubernetes or is theirs a little different?

    Zalman: I think Betterment has a particular approach to locking down access which is, you literally get this much access or this much access or this much access or over here, maybe this much access. It’s highly tailored and fine-tuned, and I think that is the—that’s sort of the forward thinking way. Like, people talk about lease privilege and Betterment has actually implemented it across the board for every single thing that somebody needs access to.

    Shimel: That’s great, man. That’s—and Chris, kudos to you and your team for that, right? Because that is—look, you’re in the financial industry, you’ve gotta do what you’ve gotta do there, but that’s an excellent thing.

    Guys, we’re over time, to tell you the truth, but I kind of enjoyed the conversation today, so I let it go. But we need to break out of here. Chris, enjoy—I know you’re about to take, you said, like a week off over that at the shore and enjoy it. I see maybe you’ll get that oar off the wall and actually do something.

    Becker: [Laughter] Some paddle boarding.

    Shimel: Yeah, that sounds cool. Anyway, I’m just thinking, I’m supposed to be going out on the boat tomorrow, but it’s also supposed to rain, so I’m not sure. But anyway, enjoy your week off. Thanks for joining us, thanks to Betterment for allowing you to tell your story here today.

    Liz, always a pleasure to have you on and hear more about strongDM and this whole kind of—you know, these new companies, not necessarily new like today new, but a new way of doing things and a new way of making it easy to bring people on and access assets wherever the infrastructure is, so—fantastic.

    We’re gonna wrap. This is Alan Shimel for TechStrong TV. We’re going to be right back with our next guest.

  • The Importance of Digital Certificates to DevOps Teams

    The Importance of Digital Certificates to DevOps Teams

    Certificate management is an important element of ensuring DevOps processes run smoothly

    Organizations are increasingly integrating DevOps into their app development processes. According to Amazon Web Services (AWS), DevOps holds so much promise with organizations because it has the potential to increase the speed and ability to deploy new apps and services. Together, development and operations personnel use extended technology stacks and tooling to automate processes that they’ve traditionally fulfilled manually.

    Organizations want to get the most out of integrating their different teams together under a DevOps model. It’s not surprising, therefore, that DevOps is constantly changing in an attempt to fit the ever-evolving technology landscape, including IT security.

    Sid Phadkar, senior product manager at Akamai, made this point clear to TechRepublic:

    With the rising number of data breaches and increased emphasis on data privacy regulations such as PSD2 and GDPR both in the U.S. and globally, DevOps-savvy organizations will be forced to prioritize diligence in security measures overtime to market in the year ahead. As new regulations are put into place, more application developers will be mandated to build strict security policies directly within code. There will be an uptick in DevOps tools that cater to automating more compliance-related tasks within infosec teams, thus incorporating security and compliance measures into everyday CI workflows.

    The issue is that it’s not always easy to align DevOps with security. Good security practices commonly come into contact with the timely delivery of a new application or a service. Without the right tools to support DevOps, security personnel can’t support developers in a way that they need to be supported. As a result, developers will be more inclined to resist new security practices and find non-compliant alternatives to new processes that slow them down.

    These challenges are of special concern for certificate lifecycle management. Organizations need to secure the DevOps life cycle with PKI via code signing or creating a certificate. But, this implementation of PKI often suffers from poor visibility into certificate life cycles and inconsistent communication with Certificate Authorities.

    Conventional DevOps pipelines also commonly rely on manual requests to obtain trusted certificates. These types of requests undermine the agility of the software development life cycle. Most containers aren’t up for very long, so if those requests take days to complete, the resulting digital certificates will be effectively useless unless the organization slows down its delivery of applications. Such dynamism also makes it difficult for DevOps to manage and monitor those certificates on their own. Team members could therefore look for shortcuts, resort to ad hoc processes or purchase certificates that use multiple cryptographic standards—variations that increase the organization’s security risk.

    These concerns don’t resonate only with industry analysts. They’re also shared by DevOps professionals. In a 2019 survey, 74% of DevOps professionals told Venafi they were concerned that issuing certificates could slow down development. Just over a third (39%) of developers said they should be able to circumvent those policies to meet their service-level agreements, while less than half (48%) of respondents voiced their belief that developers in their organization always request certificates through channels and methods approved by the security team.

    How DevOps Teams Can Best Handle Their Certificates

    DevOps teams can best handle their certificates by automating their certificate management processes. Orchestration tools such as Kubernetes support certificate management via the ACME protocol. Kubernetes stores private keys in the Kubernetes Secret or Hashicorp Vault, thus providing seamless integration for the certificate management system. DevOps teams can also digitally sign their containers with a private CA to help verify a given container as it communicates over a TLS connection.

    Aside from automation, DevOps needs to increase the visibility of their certificates to avoid unnecessary outages. Team members need to be able to renew certificates before they expire and to address improper configurations to make sure that critical services remain up. API-driven automation can help orchestrate their processes involving keys and certificates in an attempt to balance both agility and security.

  • Should Conway’s Law Be Applied to DevSecOps?

    Should Conway’s Law Be Applied to DevSecOps?

    Strictly adhering to Conway’s Law could lead to less innovation and the inability to keep up in a fast-changing market

    When it comes to determining how an organization should be structured, the 1967 Conway’s Law provides a plausible direction that many software companies could follow. However, in today’s ever-changing cloud environment, it is arguable whether it can be used in DevSecOps companies, a quickly growing organization structure. While Conway’s Law is helpful to consider, it should only be used as a guideline and not strictly followed because it can lead to less innovation and the inability to keep up with the fast-changing market.

    What is Conway’s Law?

    Conway’s Law is a term that originated from engineer Melvin Conway’s 1967 thesis paper to Harvard Business Review. In his submission, he wrote that “any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication methods.” Based on his observations in the engineering world, he believed that the success of a software is based on the organization’s company structure and communication style. As a result of this paper, software companies began to emphasize collaboration and teamwork and implemented it into the company’s work culture.

    How Can Conway’s Law Apply to the DevSecOps Field?

    Conway’s Law has many valid points. The law emphasizes the importance of a company’s structure and the necessary balance of business and design to ensure a viable product, as the quality of a product “comes from within.” However, there is no right way to organize a company, and it should be structured in a way that makes the most sense for an evolving, cloud-based product.

    In the DevSecOps field, many solutions are run by enterprises that are cloud-based. This means that all the data and networks are stored in remote servers, making it easier for companies to constantly develop new technology and improve existing products. This new norm is redefining the way companies are structured today, and traditional standards cannot be followed. If a company strictly follows Conway’s Law, it will be difficult for them to innovate.

    Here are a couple of takeaways from Conway’s Law that can benefit DevSecOps companies:

    Small Teams With Equal Representation

    Conway’s Law explains that the bigger the team, the higher likelihood of miscommunication and tension, causing unproductivity. Many tech companies, such as Microsoft and Amazon, structure their employees in small teams (around 10-15 members) to oversee and specialize in a specific aspect in the company’s product, but aim to achieve the same business goal. This type of structure allows more leeway to experiment different ideas and quicker response time to fast-changing needs.

    Collaboration is Key

    Some argue that following Conway’s Law may decrease the company’s overall cooperation and lead to small team allegiance. While there is a fine line between small work groups and department cliques, collaboration needs to be a core concept embedded in the company’s organization.

    If the organization’s culture is based on companywide collaboration, it will solve these problems, as collaborative processes and platforms prevent cliques from forming and allow teams to be independent, creative and agile. For example, for security teams to successfully collaborate with DevOps teams, they need to intentionally create solutions that can be embedded with existing DevOps pipelines.

    Conclusion

    While Conway’s Law is an important social contribution to organization principles, it should only be used as a rough guideline because following it too closely can stymie innovation in a fast-changing cloud environment. Conway’s Law highlights the importance of company structure and implies that a successful organization is structured with small teams focusing on one sector of the company, and with consistent collaboration established throughout the company to systematize unification and togetherness.

    As organizations compete for the greatest slice of pie, it is critical for leaders to look inward and ensure internal structures and processes are setting their products up for success.

  • The Role of DevSecOps in Finance App Dev

    The Role of DevSecOps in Finance App Dev

    DevSecOps is critical in developing apps successfully in the rapidly changing and highly regulated finance environment

    One of the most important shifts of the past few years in finance and banking was the movement from primarily branch-based banks to mobile-first banks. While these innovative products simplify the end user experience, they also bring up more security concerns, since digital channels expose a number of vulnerabilities. These apps deal with sensitive user data, such as private financial or personal information, which means that the prevention of any type of breach is of utmost importance.

    The level of security of a finance app is judged primarily on how well digital transactions and personal data are protected online. Even the smallest security concern can mean that users lose confidence in the app and immediately switch to another provider, often leaving negative reviews in the app stores and damaging the reputation of the company. It does not come as a surprise that the finance industry is one of the most regulated industries in the world: finance apps are required to fulfill the strictest security requirements and offer the latest functionalities at the same time.

    Regulatory Concerns in the Finance and Banking Industry

    Not only do finance app companies have to comply with traditional finance regulations, but they also are subject to international and local privacy laws. One example is the EU’s General Data Protection Regulation (GDPR), which came into effect in May 2018 and requires companies with ties to the European market to update their data and privacy policies. This affects the finance and banking industry in a number of ways, especially when it comes to getting consent before processing the personal data of users, the right of the clients to request their data to be erased, and additional penalties for data breaches and for failing to comply with such regulations.

    Another recent example of changing regulations affecting the finance and banking industry in Europe is the Strong Customer Authentication requirement (SCA), implemented in September 2019. According to this regulation, a secure finance app requires at least two forms of independent authentication elements from its users. These can either be a knowledge element: something only the user knows, such as a password; a possession element: something only the user possesses, such as their smartphone; or an inherence element: something the user is, such as their fingerprint.

    Meanwhile, in the United States, the number of potentially applicable regulations make this an even more complex issue. Here, finance app companies might be subjected to a plethora of federal or state licensing or registration requirements and thereby may have to adhere to laws and regulations on both levels, depending on their activity. Providing fintech services in the United States often requires licensing and registration with multiple state regulators including consumer lending, money transmission and virtual currency licenses.

    These examples show the additional challenges finance app companies are facing throughout the already challenging mobile development process. Things can be further complicated when developers have to build an app for a global audience with different requirements per country or region. Such companies often have codebases running in multiple different countries; having to manage this complexity while following a variety of regulations can even cause delays in important product releases.

    Growing Customer Expectations Require a New Approach

    Continuously improving features, maintaining app quality and responding to constantly changing requirements can be a daily challenge for product managers and developers. To tackle these issues, it’s necessary to implement a set of security processes from as early as the planning phase all the way to release—in other words, to create a DevSecOps environment. This can be facilitated by integrating regular information security checks and core security tasks into the software development life cycle to remove previously existing bottlenecks between developers, the security team and the rest of the organization. This approach also helps mitigate risks and allow all contributors to take more ownership and avoid security-related failures.

    A DevSecOps environment in the finance or any sector also enables teams to have full control over their stacks and access management and to be able to monitor any and all access within and outside of their environment at all times. Another step forward is shifting the responsibility of security maintenance from the team to a secure and scalable cloud-based CI/CD platform. Automation early on helps developers focus on what matters the most: optimizing their product and developing new features without having to worry about security-related maintenance tasks. It also leaves more time for parts of the process that are essential for safeguarding quality, such as checking code dependencies, threat modeling and detecting flaws before a release.

    Building the future’s successful apps in this rapidly changing and heavily regulated space will require adopting an agile, technology-forward mindset and organizational change at the same pace. In the finance industry, it’s especially important to make not only DevOps but also DevSecOps integral parts of the software development life cycle. Only this way can vulnerabilities be minimized across all applications and the different parts of the organization. Fintech, finance and banking apps can only remain competitive if they have solid structural support that enables them to securely connect to—and protect—their users.

  • 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.

  • 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.