Tag: code

  • Camunda Extends Reach of BPM Platform

    Camunda Extends Reach of BPM Platform

    Camunda, a provider of a business process management (BPM) platform written in Java, this week added support for an open application programming interface (API) to make it easier to integrate its namesake software with applications written in Javascript/Node.js, Python and C#.

    Company CTO Daniel Mayer said at a time when many organizations are investing in digital business transformation initiatives, the latest updates to the Camunda BPM platform adds support for an OpenAPI standard advanced by The Linux Foundation to enable IT organizations to integrate business processes spanning modules created using different programming languages. In the case of Camunda, IT organizations will be able to generate a REST API client using their preferred coding language that can be integrated with the core Camunda BPM platform, he said.

    In addition, Camunda announced that version 7.13 of the Camunda BPM platform will be available in the form of a lightweight distribution, dubbed Camunda BPM Run, that can be deployed as a Docker container to create a standalone engine with no Java or application server knowledge required.

    Camunda has also added support for Camunda’s Optimize 3.0 to provide a unified view of real-time process insights from any data source and the ability to visually track changes across different versions of process models using its Cawemo tool.

    Finally, Camunda has added support for version 1.3 of the Decision Model and Notation (DMN) specification as well as version 1.2 of the Friendly Enough Expression Language (FEEL) defined by The Object Management Group.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, many organizations are looking to reduce costs by streamlining business processes. The decision many of them need to make is determining to what degree they want to rely on packaged applications to achieve that goal versus a platform that enables them to create custom business processes. While many rote processes can be automated using packaged applications, Mayer said the Camunda platform makes it possible to create business processes that truly differentiate organizations from rivals. Packaged applications, in contrast, drive organizations to employ the same business processes in the same way.

    Of course, organizations can customize packaged applications. However, at that point, most of them will have embarked on an application development project that would be easier to complete using a platform designed for that purpose, he noted.

    Naturally, there are other platforms for integrating business processes that revolve around graphical user interfaces. Camunda has been making the case for an open source Java-based platform that enables developers to create and deploy custom business processes using best DevOps practices at a much lower total cost. The company also commercially makes available an enterprise edition of its platform. In total, Camunda claims there are now than 100,000 developers participating in the Camunda community.

    It’s too early to determine to what degree organizations will rely on packaged applications versus BPM platforms to drive digital business transformation initiatives. However, given the current economic climate, it’s apparent these projects have never been more urgent.

  • Survey Surfaces Tension Between Software Speed and Quality

    Survey Surfaces Tension Between Software Speed and Quality

    A survey of 600 software professionals at organizations with more than 1,000 employees published today by OverOps, a provider of software analytics tools, finds the need to ensure quality still trumps the need for speed within most organizations.

    According to the survey results, 70% of respondents say quality is their paramount concern and they would rather delay a product road map than risk a critical error impacting their users. More than half of the survey respondents (53%) said they encounter such critical or customer-impacting issues in production at least one or more times a month. Two out of three survey participants report spending at least a day per week troubleshooting issues in their code, with 30% spending anywhere from two days to a full week.

    Nevertheless, organizations continue to invest DevOps (58%) to accelerate application development. Among those organizations, continuous integration (54%) and continuous delivery (42%) platforms were the top priority.

    Other areas of investment include microservices/containers (45%), static analysis (37%) and dynamic code analysis (27%).

    Nearly half of respondents (45%) said pressure to move fast was one of their top software quality challenges. More than half of respondents (59%) said they release new code/features anywhere from bi-weekly to multiple times a day.

    Despite investments in DevOps, however, a quarter of participants also said that over 40% of critical production issues are first reported by end users or customers rather than internal systems.

    OverOps CTO Tal Weiss said the survey makes it clear there needs to be more focus on software quality. The challenge organizations face is finding a way to achieve that goal while still accelerating the rate at which code is delivered. Too many organizations are measuring the lines of code delivered without taking into account how often they run into issues in production environments because of the quality of the code deployed.

    Of course, whenever a project falls behind one of the first places any organization looks to make up ground is by reducing the amount of time allocated to testing. However, many organizations are also integrating testing within CI/CD platforms to make sure critical testing processes are not skipped in the name of making a deadline.

    It’s not clear whether software being deployed today is any higher or lower in quality than software developed using legacy waterfall approaches. As long as humans write code, there will always be issues. Proponents of DevOps will argue that deploying smaller amounts of code more frequently helps mitigate that issue. If errors are discovered, it’s easier for DevOps teams to not only roll back that smaller update but also more quickly discover the source of any issue. Sometimes that issue may have more to do with the platform the code is being deployed on than the code itself.

    Regardless of the approach to developing software, there is clearly more at stake than ever. As organizations embrace digital business transformation the quality of any software update can have a major impact on the business. The challenge is first eliminating as many of those disruptions as possible and then, secondly, minimizing their potential impact on the business as quickly as possible.

  • GitLab Responds To GitHub Making Teams Free – We All Win

    GitLab Responds To GitHub Making Teams Free – We All Win

    Microsoft’s GitHub recently announced that it was going to make a change to its product lineup by making the team version of GitHub free and lowering the price on a full-featured version. The move seemed aimed squarely at matching GitLab’s offering. Well, now GitLab has responded to GitHub.

    While both of these excellent offerings compete to bring the best product to market, the real winners here are all of us. True market dynamics are at play resulting in both GitLab and GitHub lowering prices and adding more features (and not just GitHub and GitLab but also their competitors, including Atlassian among others).

    I had a chance to sit down with Sid Sijbrandij to discuss GitHub’s move, what GitLab will do and what this means for the market. (BTW, I have to apologize to Sid—it seems I have been mispronouncing his name for years and he is too much of a gentleman to correct me. The proper pronunciation of his name is “See Brandy.”) The video of our conversation appears below, and a blog on the GitLab site explains it all.

    In our interview, Sid was very clear that GitLab owes a huge amount of gratitude to GitHub, as it was GitHub that spurred on the early development of GitLab. He truly respects what GitHub has done, as well as the great job Microsoft has done since acquiring GitHub.

    The GitLab blog post lays out very clearly what the GitHub offering is and how it compares to the GitLab offering. It’s no coincidence that the new GitHub paid teams offering is the same price as the GitLab bronze offering.

    Price aside, according to Sid, the real advantage of GitLab is that its vision of an end-to-end total DevOps solution and the features it adds to achieve this vision give GitLab customers more than they can get from GitHub. While I agree that is true today, I don’t think GitHub is going to be content with its current lineup for long. I think the Microsoft entity already envisions a total DevOps solution as being part of GitHub’s future.

    On top of that, I think GitHub and Microsoft are already thinking of how they can leverage Azure to give GitHub an advantage. To Microsoft’s credit, though, at least until now there has not been any special advantage of using GitHub with Azure. Azure remains an open platform that all vendors seem to get fair access to and support from.

    All of this aside though, we are all the real winners here. What a great time to be a developer/DevOps professional. While GitLab and GitHub compete with each other to bring more features to market for less money, as I mentioned other companies are competing to bring end-to-end DevOps solutions to market as well. We benefit from all of this competition by getting better tools and solutions at better prices. That’s true market dynamics at work.

    It should get only better in the months and years ahead as well. In spite of COVID19 and the rest, it is a great time to be alive.

    — Alan Shimel

  • Stackery Smooths AWS Serverless Integration for DevOps

    Stackery Smooths AWS Serverless Integration for DevOps

    Stackery today announced a plug-in capability that will allow developers to build and debug code destined to run on the Lambda serverless computing service provided by Amazon Web Services (AWS) from within an integrated development environment (IDE) running on a local machine.

    Company CTO Chase Douglas said the latest Stackery tool can be dropped into any IDE, either via a Stackery VS Code Serverless Tools Plug-In that automates installation or a manual installation process, regardless of the programming language being employed. The goal is to make it easier for DevOps teams to construct workflows that include AWS serverless computing frameworks, which now are expanding rapidly, he said. In total, the Stackery tools can invoke any one of 86 AWS CloudFormation-compatible resources.

    Stackery provides a set of visual tools that make it easier to write functions for the AWS Lambda service without having to know how to create YAML files to manipulate infrastructure as code. This latest offering extends that capability to local environments, which will allow DevOps teams to work offline on their laptops and make changes without having to make every change on the AWS cloud over an internet connection. This capability does not require customers to set up a Stackery account to use it.

    Right now, Stackery is squarely focused on providing those tools for AWS environments, but Thomas said eventually those tools will be extended to other serverless computing environments.

    The goal is to provide DevOps teams with tools that make all serverless computing frameworks more accessible to both developers and IT operations teams, Douglas said.

    Serverless computing frameworks are gaining in popularity because they make it easier for developers to invoke additional IT infrastructure resources to kick off, for example, an analytics module whenever a certain event occurs within their application. That capability reduces the amount of code developers need to include in their core applications. Serverless computing frameworks are usually employed to run stateless processes for a very short amount of time, while containers and virtual machines continue to be relied on for running longer running applications. But for DevOps, that creates another layer of abstraction to include within the context of a larger continuous integration/continuous deployment workflow.

    Most organizations are already struggling with mastering the workflows they employ to manage the building and deployment of applications using containers and virtual machines, so any new abstraction layer of compute resources need to incorporate within the workflows easily if the providers of that service hope to achieve mainstream adoption among DevOps practitioners. Long-term, of course, the expectation is all these processes will be completely automated, which means developers only will have to ever worry about writing business logic.

    In the meantime, it’s likely to be a while before DevOps shops are invoking multiple serverless computing frameworks running on different clouds, much less automating them on end to end. That day, however, may not be as far off as people today might assume.

    — Mike Vizard

  • GitLab Survey Surfaces Major DevSecOps Challenges Ahead

    GitLab Survey Surfaces Major DevSecOps Challenges Ahead

    A report based on a survey of 4,071 software professionals published this week by GitLab, a provider of a continuous integration and continuous deployment (CI/CD) platform, found that while appreciation of the potential value of DevSecOps best practices is high, the ability to implement those practices is uneven at best.

    According to the survey, half of the respondents reported that security vulnerabilities are discovered mostly by the security team rather than developers after code is merged and in a test environment. And, when cybersecurity professionals participate in a DevSecOps process, the survey found those organizations are three times more likely to discover bugs before code is merged. In addition, a full 90% of those organizations are more likely to have tested between 91% and 100% of their code early in the development process.

    Obviously, that’s better than discovering them after they’ve been deployed in a production environment. On the downside, however, nearly half of security professionals participating in the GitLab survey (49%) said they struggle to get developers to make remediation of vulnerabilities a priority. That challenge may reflect the overall maturity of the DevSecOps practices in place. For example, only 25% of developers participating in the survey rated their security practices as being good. That compares to only 20% of security professionals who rated their processes as good. Only 14% of respondents said they are relying on application security tools to test more than 91% of their code. A full 44% are using these types of tools to test less than a third of their code.

    Priyanka Sharma, director of technology evangelism for GitLab, said the survey makes it clear that DevSecOps is now officially a thing in the enterprise. However, only 44% of the survey respondents said that security vulnerabilities are a performance metric for developers in their organizations. As such, it’s clear there is still a long way to go before anything approaching DevSecOps nirvana is likely to be achieved. In fact, Sharma noted building and deploying more secure applications may require organizations to slow down the rate at which applications are being built, at least initially.

    The GitLab survey makes it clear most organizations are still struggling with mastering DevOps. Only 28% of developers said they feel good about their organization’s level of DevOps sophistication, while less than half (45%) said they have been able to implement continuous code deployment at least somewhere in their organization. That level of adoption suggests there still is plenty of opportunity to refine DevOps processes that are not fully ingrained. In fact, it appears most organizations are still trying to master agile development methodologies—more than half of the respondents said they employ Scrum (54%) as their application development methodology, followed by Kanban at 37% and DevOps at 36%.

    Ultimately, most organizations will have no choice when it comes to embracing DevSecOps. There simply are not enough cybersecurity professionals available to secure every application on their own. That means developers will need to assume more responsibility for cybersecurity, regardless of whether they like it. DevSecOps processes will be required to validate whether developers have implemented all the security patches and controls required. Anything less than that going forward will be deemed as nothing short of reckless—which, as any lawyer will gladly share, means much higher penalties for everyone involved.

    — Mike Vizard

  • DevOps Chat: Repos and Nexus Firewall Access, with Sonatype

    DevOps Chat: Repos and Nexus Firewall Access, with Sonatype

    There are really only two repositories of any scale for software components today: the Nexus repo managed by Sonatype and the Artifactory artifact repo managed by JFrog. Up until now they were separate and apart, and working with one was independent of another.

    In a big move toward keeping DevOps open and secure, the Sonatype people have released a plugin that will allow their Nexus Firewall to work with Artifactory as well as Nexus.

    This means that users of both repos can now use the Nexus firewall to make sure that components or artifacts they download are in compliance with the policies they have set up. They can make sure there are no known vulnerabilities to the version users are downloading to use. This is really a big deal and kudos to Sonatype.

    In this DevOps Chat we speak with Wayne Jackson, CEO of Sonatype, and Brian Fox, CTO and co-founder of Sonatype, about what this means for the DevOps community.

    Transcript

    Alan Shimel: Hey, everyone. It’s Alan Shimel, devopsy.kinsta.cloud, and you’re listening to another DevOps Chat. Today’s DevOps Chat is breaking some big news from our friends at Sonatype. I’m really honored and happy to be joined by Sonatype Wayne Jackson and Sonatype CF – CTO, Brian Fox. I hope I didn’t mess that up, guys. Wayne, Brian, welcome.

    Brian Fox: Thanks.

    Jackson: Thank you, Alan. Great to be with you and great to be speaking again.

    Shimel: Yeah. Well, Wayne, you and I go back just a couple years.

    Jackson: [Laughs]

    Shimel: Let’s not go and do a history thing. Let’s get right to the breaking news today, and that is kind of a major addition to the Sonatype – I know it’s a firewall. Do you still call it Nexus Firewall or is there a different name for it now?

    Jackson: Yes, we – yeah, that’s correct.

    Shimel: It is the Nexus Firewall. So before we talk about what the major addition is, let’s lay a little groundwork here. What is the Nexus Firewall? Brian, you’re the CTO, let’s give that one to you.

    Fox: Alright, sure. Nexus Firewall is a set of capabilities that allow us to do analysis of components as you pull them into your supply chain through your repository and be able to match that against your policies to enforce things like architecture, quality, license, et cetera, and so specifically it’s intended to be able to stop components from coming into your supply chain when they’re known to be against your policy right up front. So you can stop developers from pulling in a component that has a known vulnerability or pulling in a component that has a incompatible license, those types of things. So that’s the role Firewall plays in the overall portfolio.

    Shimel: Perfect. And, you know, let’s be clear; that – you know, a Nexus Firewall, if it’s in place the Equifax breach never happens for all intents and purposes.

    Fox: Well, that might – what it doesn’t do – you know, it’s not gonna go back and take out the things you’re already input.

    Shimel: You’ve already put in, you’re right.

    Fox: Right. Certainly. If – you know, we still see lots of cases – I think we’ve done some of the studies recently that show organizations are still downloading the same thing that got Equifax attacked, right?

    Shimel: Absolutely.

    Fox: It’s the same version of Strut. So, Firewall would definitely stop that behavior, no doubt, and be able to prevent it from further propagating through your supply chain.

    Shimel: And just a little shout out, Equifax is now a Nexus – a Sonatype Nexus customer, correct?

    Fox: Yeah, that’s correct.

    Jackson: Yes, that’s correct.

    Shimel: So hope – well, at least it’ll prevent the next one, hopefully. So – but guys, so we understand what Nexus Firewall is now, and again, to put in context the importance of today’s announcement, Nexus Firewall worked when you were pulling components out of the Nexus repository up until now. Am I right or am I off base here, guys?

    Jackson: No, that’s correct.

    Shimel: And so the big news today is you’re expanding beyond the Nexus repository to offer protection from artifacts and code and so forth from other repositories.

    Jackson: That’s right. It’s – you know, it’s an acknowledgement, and it may be the first one in this category, that just acknowledges that the DevOps world is heterogenous. You know, there are bunches of vendors and, you know, people within organizations make different decisions and we just acknowledge the need to provide universal protection.

    Shimel: Absolutely. So Wayne, work with me here. It’s the Nexus repository, and with this new release out today you guys are also announcing support and protection for the Artifactory repository, correct?

    Jackson: That’s correct.

    Shimel: And –

    Jackson: And between those two, you know, I’m not sure what the coverage is but it’s gotta be in the 90th percentile of implemented repositories.

    Shimel: I would agree with you. I think between Artifactory and Nexus it’s gotta be I would say high 90’s even, right? We’re not talking 91 or 92 percent. I think it’s probably way up there, and it’s certainly in the billions when you look at the amount of whether it be code or components or artifacts that are contained between the two of them. And Wayne, you hit on it before about the heterogenous nature of today’s DevOps world. It really is; it’s become Artifactory and Nexus as the two big ones.

    But there’s another aspect to the heterogenous nature of today’s DevOps world and that is this whole notion of the software development life cycle, managing the software pipeline, the modern software factory; different companies are calling it different things but it all refers to kind of the way that software is being both written and assembled in – by, you know, modern IT departments today. Why don’t you guys expand on that a little bit.

    Jackson: Yeah, I – it’s been fascinating to watch. As you know, I came from the network security world before Sonatype and had no grasp of just how much software was being written. As I’m sure you know, you know, one of the assets that we manage in the ecosystem is this thing called Maven Central, and last year we served 142 billion download requests, and so – and that’s just in the Java ecosystem and, you know, other ecosystems like NPM are just as big.

    Shimel: Yeah.

    Jackson: And so as we started looking at the patterns in these download requests we started to see this weird disconnect. You know, the disclosure of a vulnerability had almost no impact on usage patterns, and that led us to thinking about, you know, why that might be and how we might think about solving these problems more systematically, and it dawned on us that we had a massive supply chain problem. You know, where the producers of things didn’t have a very effective mechanism for communicating to the consumers of those things because there were just millions and millions of projects that had to be monitored. And so, you know, we started looking at the works of Edwards Deming, who was the guy that transformed Toyota from being a textile manufacturer to the world’s most efficient automobile producer, and it really wasn’t all that complicated. You know, you have fewer, better suppliers, you use the highest quality parts, maintain transparency throughout the system, and don’t pass defects downstream.

    If you can do those four things, lo and behold, [laughs] producing cars becomes a lot easier. And, you know, we concluded that those exact same principles applied perfectly to software where, you know, to your point, you know, now all of a sudden these software development functions, especially in the more modern organizations, look like a software factory, and so let’s use fewer, better projects, let’s use the versions of those projects that don’t have security defects, that have the kind of license that matches our  distribution model and, you know, let’s build a model where we know [laughs] what’s in the system. And if along the software factory assembly line we discover that there’s an issue, stop it there. You know, don’t pass it downstream.

    So anyway, so it’s a model – you know, I’m a little bit of a car guy so it [laughs] certainly works for me, but it feels like a model that’s right.

    Shimel: I agree. It absolutely does. And even before you mentioned Deming, and of course it’s obvious, I was thinking third-party suppliers just like we do see in the automobile industry. But what’s interesting is as you referenced, the sheer magnitude of the numbers here – you know, 142 billion – think about what that means. I mean it’s just an incredible, incredible amount of downloads of usage and everything else and, you know, it doesn’t take many bad apples to spoil the party for everyone, obviously. You know what’s interesting though, guys? Again, getting back to the DevOps community, the DevOps market today, Sonatype is very much – you know, who you are and what – it seems to me anyway – you know who you are, what you are, where you play and how you fit into this.

    And I think that’s in contrast to – you know, we’re in a little bit of a time of upheaval in the DevOps spaces as the market matures and vendors are jostling and trying to – I think some of them might, you know, even be going through an awkward teenage phase, you know, where they’re trying to figure out who they are and what they’re gonna be when they grow up. You know, what – Wayne, you’re the CEO there – what’s the vision for Sonatype? Are you kind of comfortable in your own skin now and what is that role?

    Jackson: Yeah. I think we are comfortable in our skin. I think this embrace of software supply chain management is who we are, it’s who we’re going to be, it’s sort of a unique position to take in the DevOps category, and it allows us to play very nicely with the vendors that are all a part of the assembly line, you know, whether it’s Artifactory or CloudBees or any of the other vendors. And so being able to produce information that gets translated into knowledge that, you know, automates decision-making with regard to supply chain integrity, I think is a good spot for us.

    Shimel: I agree. I mean and not only is a good spot I think it’s a pivotal role to play at this – you know, as we see the continued maturation of the market and, you know, it’s all wrapped around the digital transformation and everything going on. Brian, you know, your background, you were an early chair of the Maven Project. You’ve been in this opensource, you know, world for some time, and Wayne did too coming from the Sourcefire Snort folks, but what’s your take as we see this, you know, maturation? I mean at some level it’s gotta be – I would imagine it’s gotta be encouraging to see cross – like, you know, being able to protect across different repositories, whether it be Maven and Java or Artifacts or what have you, right? It’s gotta feel like we’re making progress. What do you think?

    Fox: Yeah, I think so. I mean our approach since we kind of went down this path, what, 2012 or so is to take an approach that sits above all of the tools, because we recognize from the early days when we were doing a lot of Maven training and consulting and we had the privilege I guess to go to companies and see lots of horrifying processes and all the ways in which attempts to make this better inadvertently made things worse, and we recognize that it requires a sort of across-the-life cycle approach, which means you can’t solve the problem just by adding features to, you know, the repository or the CI. And frankly, given that we were building Nexus Repo Pro back then – I mean we still are, but that was our main product back then – adding it as features on top of the Repo would’ve been the most natural thing for us to do, but we understood through all of that learning that that wasn’t going to be sufficient.

    It required integration to the Repo and to the CI and to the build and to the release automation tools, et cetera, et cetera, right, to be able to most effectively nuance the process of the components that flow through that, because you may choose to respond to a policy violation differently when something is about to actually be pushed into production versus something that’s just happening in your – you know, on every commit CI build. And so for that reason, being able to integrate into all of these tools, including all of the different repos, is just natural. It’s a natural evolution of the approach we’ve been taking the whole time.

    Shimel: Got it. So, I guess the next question is now that we have – you know, between the two repositories we’ve got high 90 percent of the market – how do we get 90 percent coverage with this Firewall product, right? I think we’d all sleep better. You know, what is the key, guys, to getting more people to realize this is kind of a no-brainer that they need to get done here, right? I mean what do you think is preventing us from really seeing this?

    Fox: Culture. Culture and history. I think there’s a history of application security tools specifically that, you know, are prone to false-positives just by the way they worked and led – and a history of bad approaches, like I was talking about before, that tried to force bad tools onto development that ultimately led to rebellion or disuse and gear grinding, and so in some ways the security tribe I think has become a little bit afraid to engage development in a lot of organizations, right? So they very much try to work at the end of the process, try to produce lists. We know that those things tend to get ignored, that they don’t usually have a profound effect on what’s happening, and so the organizations that are really successful are the ones that, you know, can set all of that history aside and still work together in a DevSecOps type of way and, you know, look at the problem holistically and understand that, yeah, actually it makes sense. If we can stop the bad things from coming into the process to start with we don’t have to chase them out later.

    The security guys don’t have to track it in the list and the Dev guys don’t have to go rework it, right? And so, you know, that’s kind of the approach that we’ve been trying to take, that all of these different constituents have an important job to play in the success of a business and it works best when [laughs] they’re all working together, not working against each other and throwing grenades over the walls.

    Shimel: Absolutely.

    Fox: And so really, you know, the biggest hurdle to adoption in most places just simply is that culture and the history of disdain and things like that.

    Shimel: Yeah, I agree, Brian. And guys, I’m gonna tell you something. Here’s a private theory that I’ve been working on and I’m gonna be speaking about it in the months ahead. You know, we’ve worked really hard – Sonatype more than most any other vendor I can think of – to advance the cause of DevSecOps. You know, Derek and Mark on your team and myself have been putting on DevSecOps events at RSA for the last five years now, and we do it in Singapore at RSA and we go all over the world with this DevSecOps thing. And recently, in the last couple months, I’m starting to see sort of a bifurcation in how security is dealing with DevSecOps, right?

    I’m seeing some companies that are embracing the Dev sides of things, and let’s call that DevSec. They’re working with developers to make the code more secure and make sure that pre deployment and everything is tested, everything is secure, and we release really tight, good quality, right? Security is synonymous with quality, and let’s call that DevSec. Then there’s another group of vendors, Brian, that are dead into what you’re talking about, right? They’re almost afraid, intimidated, or just fed up with dealing with developers, and they’re really focusing on the post deployment aspect of things here, right, and let’s call that SecOps, because they want to work more with the Ops folks, post deployment, you know, monitoring and that kind of thing.

    And I’m not saying that there’s not a reason to do that or it’s not right to do that – it absolutely is – but when we start looking at it as DevSec and SecOps, we’re committing the same mistakes that we did to begin with and we’re losing that it is DevSecOps for a reason. It’s Dev and Ops and Sec all working together. We can’t say, “Oh, we’re gonna work with the Ops guys but not the Dev guys or vice versa.” It’s gotta be everyone’s in it to win it. And I –

    Fox: Completely agree.

    Shimel: But I’m – yeah – but I’m seeing security vendors now kind of, you know, taking sides here on this. I’ve recently done a few podcasts – and some of them are new companies that are launching or coming out of stealth and RSA, and they’re growing this distinction that they’re SecOps, not DevSecOps, or they’re DevSec, not Dev – and I think it’s a huge mistake, a huge mistake.

    Fox: I think that’s largely led by the constituent. If you go and talk to the security guys, that’s what they’re gonna tell you that they want, right? It’s part of that history.

    Shimel: Yeah.

    Fox: You know, so if you allow yourselves to be pulled directly in the direction of what people want based on their perceived understanding of just how things work and that’s the way it’s always gonna be, that’s I think where you end up, so you have to buck that trend a little bit and say, “Guys, it doesn’t have to be this way. It can be better.” But we have to work together to do it, right, and we have to think about things a little bit differently. You know, and I have many conversations – you know, it’s happening more and more as AppSec and OPSEC is becoming more generally aware of the opensource component, you know, risk. They’re starting to come at the problem, but unfortunately they’re just trying to add more data to their existing process, and I have to remind those guys all the time that developers are picking new components all the time, they’re picking new versions of those components all the time.

    They’re not only doing it because you handed them a list of vulnerable components or a list of CVEs and said, “Fix it or else,” right? So wouldn’t it be nice if you had a process and a set of tools that could support them in that behavior so they don’t come on your list later? [Laughs] Right? And a lot of times that is like a shocking realization to that tribe, right, and that’s that culture that I was talking about. It’s a big challenge.

    Shimel: Agreed. And look, our work is not done, right? That’s what that means to me. We still have more work to do evangelizing DevSecOps and making sure people under – take a whole holistic aspect to it, and it goes back, Wayne, to what you were talking about in terms of the pipeline and the software, you know, automation and pipeline kind of thing, is it’s not bifurcated at the pre deployment versus post deployment juncture or junction. It – DevSecOps is about the whole thing from end to end.

    Jackson: Yeah, the organizations that can think about this holistically are just bound to be more effective and more efficient and, you know, to your point about evangelism, I mean one of the things that we’re going to see, and I think we are seeing, is that the most highly-performing organizations are the ones that are getting it.

    Shimel: Yeah.

    Jackson: They’re the ones that are gonna be leveraging software to more effectively differentiate their business. [Laughs] And at some point, unless you want to lose, you’re gonna have to start thinking about the ways that these, you know, forward-thinking, advanced organizations are doing what they do to make themselves better every day.

    Shimel: Absolutely. And you’ll have winners and losers, and look, that’s capitalism and that’s the market dynamics at play, right? You can adapt or die or not, right? I mean it’s up to you. Guys, we’ve spent a lot of time talking, you know, about this at a macro level. Brian, if you don’t mind, I’d like to get a little geeky on you and ask if you can explain to our audience at a nuts and bolts level really what’s going on with the Nexus Firewall.

    It’s software, right? It’s not an appliance, per se. Where does it sit, how does it intersect, how do you set policies in it? You know what I’m saying? Let’s give our audience a little bit of a…

    Fox: So our Nexus platform is kind of composed of maybe three parts. At the core is a piece of software that you run on prem or in your cloud that we call the IQ Server, and this is the thing were you define your policies, it’s the database of all of the components and which applications they’re used in, the dashboarding, the reporting; you know, all of that type of stuff occurs within the IQ Server. The IQ Server works with services that we have in our cloud to provide the real-time information around the components and the security and the licensing and all that type of stuff, right? So that’s a real-time feed, it’s not a data dump that you have to download periodically.

    And then there’s all of the plugins, the plugins that go into all of the places I mentioned before; your build, your IDE, your CI, your repository, your automation tools, et cetera, right? And so what we’re talking about here is we’ve added a new plugin that plugs into JFrog Artifactory. So when a component is being proxied from an external repo, such as Maven Central, the plugin will do the analysis of the thing being requested, it will understand what it is, work with the IQ Server to understand if it’s in compliance with the policy or not, and the depending on how the policy is configured it can either allow it, it can quarantine it, or it can just outright block it, right? So that’s the same capability that we’ve had for a couple of years now inside of the Nexus repository, so it replicates that functionality for our JFrog users.

    Shimel: Fantastic. Wayne, how are we going to market with this?

    Jackson: I get that question asked to me a fair bit, and we have a very multifaceted go-to-market model. You know, we still have folks that are very senior out in key regions that are evangelizing, because this is still an immature market, but increasingly as the market’s maturing are starting to lead with product and product capabilities in our marketing function. So, a mixed model, but one that we think aligns with where the market is in terms of its maturity, you know, that will change over time.

    Shimel: Understood. Guys, we’re almost out of time. If it’s okay I wanted to return back to the DevOps market in general. Wayne, you know, you and I kind of saw the security industry mushroom, right, from let’s say early 2000’s through even 2008, ’09, ’10, you know? I – and we now have both – and have both seen the DevOps market mushroom, you know, from 2013, ’14 to today. It’s only been four or five years. And, you know, we touched on it earlier with companies trying to kind of jostle for where they are, what they do and how they fit into this brave new world. You know, put on your visionary hat, if you will. Where’s this going? Where is it – you know, is there a logical sort of conjunction of security in the DevOps? And if so, what does that mean for the broader market? What do you think?

    Jackson: I disagree with you a little bit in that – with regard to DevOps having mushroomed. I think we in the industry kind of feel like it has because now all of the sudden people are starting to use our words back at us, but I think in terms of, you know, DevSecOps being a mainstream thing that’s just a part of how people work is still a bit away, and I think, you know, the work that you’re doing, I think the work that we’re doing and other vendors in this space is still enormously critical because even organizations that aspire to DevSecOps still need help. It’s not an easy thing to embrace and implement, as you know, and so there’s still some work to do, which I think is cool.

    Shimel: Yeah. Well, it keeps me going every day and gets me up. And you’re right, you know, we tend to forget that we live in a bubble. When you’re a hammer, everything looks like a nail, right?

    Jackson: [Laughs] Right.

    Shimel: When you’re talking DevSecOps all the time people tend not to look at you and say, “What are you talking about?” So, you know, we kind of breathe our own exhaust, if you will. But there is, there’s a lot of work to be done, even – forget DevSecOps – even in the basic DevOps level, right? When you – a lot of companies have dabbled in DevOps but how many are truly end-to-end DevOps, right, and that number I’m gonna guess is well – is below 20 percent, probably closer to 10 percent.

    Jackson: I think you’re right, I think you’re right.

    Shimel: Yep. So our work is still in front of us. But hey, you know what? It wouldn’t be fun if it wasn’t, right? I mean that’s what keeps us –

    Jackson: [Laughs]

    Shimel: Anyway, guys, when is this new plugin for Nexus Firewall available?

    Jackson: More or less now.

    Shimel: Okay.

    Jackson: I think the official release date is March 1, but yeah, happy to show it to anyone who’s curious to see and very proud of the technology.

    Shimel: Absolutely. And they can get more information at Sonatype.com?

    Jackson: That’s right.

    Shimel: Fantastic. Wayne Jackson, Brian Fox, CEO and CTO, cofounder of Sonatype, respectively. Thanks for being our guests on this episode of DevOps Chat.

    Wayne Jackson: Thank you. It’s been our pleasure.

    Fox: Thanks for having us.

    Shimel: Always a pleasure. Always a great time, guys. Okay, this is Alan Shimel for devopsy.kinsta.cloud. You’ve just listened to another DevOps Chat. Have a great day, everyone.

     

    [End of Audio]

    — Alan Shimel

  • DevSecOps: Old Security Bugs Still Performing New Tricks

    DevSecOps: Old Security Bugs Still Performing New Tricks

    New Security Flaws Creep into Reliable Old Systems

    In cybersecurity, we are often like hunters. Our eyes are firmly glued to the horizon, scanning for the next breakout vulnerability (along with the right designing tools, techniques and tactics to stop it). However, this forward-looking focus can have the surprising effect of dampening our overall security awareness, blinding us to deep-seated dangers that exist all around, and which attackers are all too happy to exploit.

    I often compare modern cybersecurity to a suit of Kevlar armor. The seemingly ethereal properties of Kevlar can block high-velocity rounds and all manner of modern, powerful weaponry. It may even make a wearer feel somewhat invincible. However, a comparatively ancient bow and arrow weapon system, first crafted sometime around 1000 B.C., can often penetrate that protection. A sharp knife, probably the second oldest weapon in the world behind rocks, can slice right though Kevlar as easily as if it were shredding a cotton sweatshirt. And then there’s the little matter of Kevlar not being able to protect every single millimeter of the human body. If an attacker can find any gap to deliver a damaging blow, they will—much like small, exploitable areas in software.

    In cybersecurity, many organizations are similarly vulnerable to flaws on systems that are eight or 10 years old, which in modern computing terms just about qualifies them for a gold watch and a pension. But if you think flaws on these elderly systems are harmless, then you’ve probably got a blue screen of death or two in your future.

    A Vulnerability for a Veteran

    One of the oldest and most used JavaScript libraries is jQuery, an open source resource that helps with everything from event handling, to DOM tree traversal and manipulation, to generating animations. It’s quite a workhorse, and has been used for many years. People assume that because the library is so established at this point, that it must have been completely vetted, with any vulnerabilities removed.

    Sadly, this is not the case. By default, most applications that rely on jQuery use the internal library’s instructions for authentication. For example, with Apache servers, this means checking the .htaccess files. Few developers designing programs that use Apache probably thought to check to make sure that Apache server updates included .htaccess. After all, why would Apache remove that critical component, which has been a bedrock of security for years?

    As strange as it may seem, that is exactly what Apache did in version 2.3.9. Apparently, having to check the .htaccess configuration files every time a program needed to run was slowing things down too much. Removing it improved overall Apache performance, but also created a vulnerability that most people didn’t know about. If developers didn’t bother to check to see if their apps could still reach the .htaccess files, most requests would simply be accepted without scrutiny.

    Recently, experts discovered that flaw and noted that using it would allow unauthorized users to upload and run shells or almost any type of code on supposedly secure systems. This led to the creation of a vulnerability alert designated CVE-2018-9206 in October. But, the ease at which the flaw was discovered by a security researcher implies that professional hackers, whose sole aim is to search for vulnerabilities such as this, probably already have discovered it. After all, despite the publicity, patches and fixes brought about in the aftermath, a similar high-impact attack happened just a few weeks later, in which Bitcoin-thieving malware was unleashed on a popular NPM lib downloaded by millions every week.

    The Butler Did It

    Like jQuery, Jenkins is an open source offering, and one of the most popular of its kind. With its helpful servant-like name, it makes sense that Jenkins is used as an automation server by development teams in many industries. When Jenkins is functioning correctly, it’s an extremely helpful tool. However, newly discovered flaws, and one recently uncovered crypto mining operation that is truly massive in scale, suggests that Jenkins was also doing a lot of work for the bad guys.

    One of the most dangerous Jenkins vulnerabilities is called Java deserialization, which is designated as CVE-2017-1000353. It’s a complex attack, but one that has been around for a while. An attacker must submit two requests. The first one starts a bidirectional channel for downloading which is initially rejected by the server. However, the second request adds an upload channel which contains a payload with whatever commands the attacker wants, and utilizes the payload.jar script. Once the second request is sent, the communication is allowed on unpatched Jenkins servers.

    Even on patched servers, exploits exist. For example, when running Jenkins in a Windows environment, by default it uses the NT AUTHORITYSYSTEM account to authorize users. This is dangerous because SYSTEM is granted full permissions on Windows servers. Developers can change the authority account, but often don’t. Their logic not to do so is based on the fact that Jenkins has been around forever, so people figure that any vulnerabilities have been patched a long time ago.

    Most recently, a hacker used these aging Jenkins vulnerabilities to compromise several servers. The goal was adding a crypto miner program on every vulnerable Jenkins instance they could find. The miners took up valuable computing resources in their constant search for cryptocurrency. So far, they have found approximately 10,800 Monero crypto coins, with a value of almost $3.5 million. 

    What is Old is New Again

    In both of these examples, vulnerabilities are being exploited by opportunistic attackers on platforms that many people consider to be safe. On the defensive side, the lack of security-aware development is allowing these hackers to breathe new life into old tricks. And despite a new round of success using aging vulnerabilities, many organizations have no plan in place to stop this vicious cycle.

    Just because something is old does not mean that it’s harmless. And just because common libraries and resources have been around for years doesn’t mean that they are completely secure (for example, the No. 9 entry in the current OWASP top 10 is dedicated to dealing with Using Components With Known Vulnerabilities). Only through diligence and constant security training can we protect ourselves not only from dangerous threats creeping over the horizon, but also those which have already settled insidiously into our own backyards.

    — Pieter Danhieux

  • Security and Speed: Why DevOps and Security Need to Play Nicely

    Security and Speed: Why DevOps and Security Need to Play Nicely

    It isn’t news that DevOps and IT security teams often struggle to align their departments and maintain a coherent balance between keeping a business secure and developing new applications to maintain customer interest. While security processes are a necessity, they can be deemed by DevOps teams to be manual and cumbersome, blocking the agility that makes them so effective in bringing their solutions to market. IT teams conversely feel their counterparts are prepared to sacrifice security in the name of innovation and revenue.

    Even if both teams do respect the other’s intentions, any conflict could lead to delays in both of their processes. For example, an IT team may need to make crucial updates to the network security and warn different teams they may experience some downtime during this crucial implementation. However, DevOps have typically been given more leeway in how they operate as they are so important in today’s software-driven world, and may ask for the update to be delayed so they can complete tasks or meet deadlines, leaving the IT team waiting and losing time rescheduling their own work.

    This has, unfortunately, led to a myth that DevOps teams choose to ignore security. In reality, developers are keen to know that their apps and the environment they work in are secure—but at the same time, they don’t want security to get in the way of them quickly delivering valuable new products and software features.

    So, is there a way for DevOps teams—one of the most important resources in many modern businesses—to embrace security without impacting agility? Can the integration of DevOps and security be done in a way that alleviates tensions and promotes collaboration, while actually improving both security and agility in the process?

    Yes. The secret is automation.

    Reconciliation Through Automation

    As C-suite executives are now more likely to focus on security, due to the obvious financial and reputational consequences of a breach, DevOps teams should define how they protect and secure their multiple projects and production environments. Automating security as part of the CI/CD process allows DevOps teams to easily follow company security policies because they will be embedded into the automation pipeline.

    This process can remain running with little concern, effectively minimizing stress about security. This still automates policy changes and activities so that there is a significantly reduced chance of error. Although the automation solution remains hidden, it can still be utilized at any point to view data on the vulnerabilities, compliance requirements, security policies and network connectivity, via its continuous scanning abilities.

    Additionally, DevOps teams are already familiar with automated tools in their daily operations and communications—and they are likely to be accepting of switching to a security solution that integrates with their existing processes.

    Automation is the key to creating reliable, effective and connected “DevSecOps” teams, as it makes the secure option the easy option. It combines DevOps’ existing use of automated tools to achieve their ultimate goal of continuous, on-time and on-budget deployments with security’s focus of reducing human error and maintaining continuous visibility into potential vulnerabilities.

    Encouraging Adoption

    A guiding principle of DevOps is collaboration, which is often equated with the idea of shared responsibility. To successfully embed security into the DevOps process, security teams and developers must work together and establish shared responsibility. But how?

    Some organizations may assign a security representative in each development team. This person acts as a pivotal link between the two teams, improving communication and building a balanced process that considers everyone’s mutual interests. A continuous flow of knowledge-sharing among both teams ensures a level of maturity that allows a business to secure applications and services with an automated solution.

    Security teams can begin to define “guardrail policies” that allow development teams to deploy continuously, with the caveat of having to obey security and compliance policies. This is critical for both teams. This new way of working means developers will be able to test their security posture at every step in the CI/CD pipeline and correct things when necessary, and security teams can comprehensively ensure security and compliance throughout the development process.

    Embracing Collaboration

    Any belief that there is common discord between DevOps and IT security teams is unfounded. While it cannot be denied that both teams affect each other, this is not due to conflict—it’s due to business needs. If the two teams work together, they can both achieve their goals and be part of a secure, innovative and profitable organization. The first step is to accept collaboration is a necessity and by embracing security instead of being concerned by it, DevOps teams can stay in control of how their needs work around IT teams’ processes. Then, an automated security solution can be deployed to improve the efficiency and outcomes of both departments—and, in turn, the entire organization. It’s time for DevOps to embrace DevSecOps.

    — Reuven Harrison

  • How to Troubleshoot CPU Problems

    How to Troubleshoot CPU Problems

    Diagnosing and troubleshooting CPU problems in production in cloud environments can be tricky. Your application might have millions of lines of code, so identifying the exact line of code that is causing the CPU to spike might be the equivalent of finding a needle in a haystack. This article shows how to find that needle (i.e. CPU spiking line of code) in a matter of seconds/minutes.

    To help readers better understand this troubleshooting technique, we built a sample application and deployed it to an AWS EC2 instance. This application when launched caused CPU consumption to spike up to 199.1 percent. Here are the steps we followed to troubleshoot this problem:

    1. Identify threads that consume CPU.
    2. Capture thread dumps.
    3. Identify the lines of code causing the CPU to spike.

    Identify Threads Causing CPU Spikes

    In the EC2 instance, multiple processes could be running. The first step is to identify which process is causing the CPU to spike up, and the best way to do that is to use the ‘TOP’ command present in *nix flavor of operating systems.

    Issue command ‘top’ from the console

    <<start:code>>

    $ top

    <<end:code>>

    This command will display all the processes that are running in the EC2 instance, with high CPU consuming processes displayed at the top. When we issued the command in the EC2 instance, we saw the below output:

    Fig: ‘top’ command issued from an AWS EC2 instance

    From the output you see process #31294 is consuming 199.1 percent of CPU, which is high consumption.

    Now that we know which process in the EC2 instance is causing the CPU to spike, the next step is to identify the threads within the process that are causing the spike.

    Issue command ‘top -H -p {pid}’ from the console. Example:

    <<start:code>>

    $ top -H -p 31294

    <<end:code>>

    This command will display all the threads are causing the CPU to spike in the 31294 process. When we issued this command in the EC2 instance, we received the below output:

    Fig: ‘top -H -p {pid}’ command issued from an AWS EC2 instance

    From the output you see:

    • Thread Id 31306 consuming 69.3 percent of CPU.
    • Thread Id 31307 consuming 65.6 percent of CPU.
    • Thread Id 31308 consuming 64.0 percent of CPU.
    • The remaining threads consume negligible amounts of CPU.

    Now that we have identified the threads that are causing CPU to spike, the next step is to capture thread dumps so we can identify the lines of code that are causing the CPU spikes.

    Capture Thread Dumps

    A thread dump is a snapshot of all threads that are present in the application. Thread state, stacktrace (i.e. code path that thread is executing) and thread ID-related information of each thread in the application is reported in the thread dump.

    There are eight different options to capture thread dumps. You can choose the option that is convenient to you. One of the simplest options to take thread dump is to use tool ‘jstack’ which is packaged in JDK. This tool can be found in $JAVA_HOME/bin folder. Below is the command to capture thread dump:

    <<start:code>>

    jstack -l  {pid} > {file-path}

    <<end:code>>

    where pid: is the process Id of the application, whose thread dump should be captured and file-path: is the file path where thread dump will be written to.

    Example:

    <<start:code>>

    jstack -l 31294 > /opt/tmp/threadDump.txt

    <<end:code>>

    In this example, the thread dump of the process would be generated in /opt/tmp/threadDump.txt file.

    Identify Lines of Code Causing CPU Spikes

    The next step is to analyze the thread dump to identify the lines of code that are causing the CPU to spike. We analyzed our thread dumps through fastThread, a free online thread dump analysis tool.

    Once we uploaded the captured thread dump, the tool generated this report with multiple sections. On the right top corner of the report is a search box, where we entered the IDs of the threads consuming high CPU—basically, the thread IDs that we identified in step No. 1: 31306, 31307 and 31308.

    fastThread displayed the threads’ stack trace, as shown below.

    Fig: FastThread tool displaying CPU consuming thread

    You can notice all the three threads to be in RUNNABLE state and executing this line of code:

    <<start:code>>

    com.buggyapp.cpuspike.Object1.execute(Object1.java:13)

    <<start:code>>

    Apparently following is the application source code:

    <<start:code>>

    1: package com.buggyapp.cpuspike;

    2:

    3: /**

    4: *

    5: * @author Test User

    6: */

    7: public class Object1 {

    8:

    9:         public static void execute() {

    10:

    11:                   while (true) {

    12:

    13:                               doSomething();

    14:                   }

    15:       }

    16:

    17:       public static void doSomething() {

    18:

    19:       }

    20: }

    <<end:code>>

    You can see line No. 13 in object1.java to be ‘doSomething();’. You can see that ‘doSomething()’ method is doing nothing, but it is invoked an infinite number of times because it doesn’t terminate but loops due to line No. 11. If a thread starts to loop an infinite number of times, the CPU will start to spike. That is what exactly happening in this sample program. If the non-terminating loop in line No. 11 is fixed, the CPU spike problem will go away.

    Conclusion

    To summarize, first we need to use ‘TOP’ tool to identify the thread IDs that are causing the CPU spike, then we need to capture the thread dumps. The final step is to analyze thread dumps to identify exact lines of code that are causing CPU to spike up.

    Enjoy troubleshooting and happy hacking!

    — Ram Lakshmanan

  • Anaxi Delivers Project Management App for DevOps

    Anaxi Delivers Project Management App for DevOps

    Anaxi, a provider of project management software designed specifically for DevOps teams, has made its web application generally available. The web application complements an existing iPhone application, while an Android version of the company’s project management application is still under development.

    Company CEO says Marc Verstaen said that as DevOps has evolved around multiple repositories, IT organizations are finding it challenging to keep track of code from projects they are using within what applications. Anaxi is designed to not only make it simpler to navigate repositories, but also apply analytics to track individual developer productivity and team performance. Project managers now can, for example, analyze efforts in terms of code added and removed, refactoring and code churn on a weekly basis.

    Armed with that intelligence, IT operations teams will be better able to prioritize development plans based on the dependencies that exist between the various components that make up an application, said Verstaen. The number of those dependencies is only expected to increase as organizations increasingly shift away from building monolithic applications in favor of more complex microservices architectures that promise to make the overall business more agile.

    The fundamental project management issue with repositories such as GitHub is that there is no way to categorize all the project labels that get entered as text. That makes it difficult to monitor and track all the tasks associated with a specific label or even simply browse from one task to the next, Verstaen said. Via Anaxi, project managers can edit their issues and pull requests, which are then synchronized back to their GitHub and Jira projects.

    It’s not clear to what degree the lack of sophisticated project management tools has hindered adoption of DevOps in the enterprise. Legacy approaches to application development provide project managers with a rich portfolio of applications that may serve to bias them toward one style of application development over another. But given the pressure organizations are now under to become more agile, project managers need to evolve alongside the rest of IT organization.

    Before too long many organizations may also find themselves trying to manage projects spanning multiple repositories. It’s not uncommon for development teams to favor one repository over another. Standardizing on one repository would be preferred, but not every project manager has the political capital inside their organization required to force such a decision. Many projects also now span multiple companies, each with their own repositories, that project managers may find themselves forced to navigate.

    At the same time, business leaders are making it clear they want more visibility into the pace at which applications are being developed whenever those applications are expected to generate revenue or improve the overall customer experience. In fact, project managers who can ensure projects are delivered consistently on time and within scope are invariably considered among the most valued of employees.

    — Mike Vizard