devopsy.kinsta.cloud

Tag: perforce

  • Add Static Code Analysis to Your CI/CD Pipelines

    Add Static Code Analysis to Your CI/CD Pipelines

    An efficient CI/CD pipeline is necessary for accelerating software delivery without sacrificing quality, and a static code analysis tool is an essential part of that pipeline. A static code analysis tool inspects your code as it is being written to identify defects, vulnerabilities and compliance issues — without having to run the program. What’s more, a static code analysis tool helps to ensure that your embedded code is secure, reliable and compliant. In this webinar, we will discuss how you can effectively add a static code analysis tool to your DevOps process.

     

    To read more, please visit: https://www.perforce.com/webinars/kw/add-static-code-analysis-to-ci-cd-pipelines

  • What Is AppSec? An Overview

    What Is AppSec? An Overview

    An estimated 84% of security incidents happen at the application layer. And, with the number of cybersecurity threats steadily rising year-over-year, application security (AppSec) has become absolutely essential.

    Application security refers to finding, fixing and preventing cybersecurity vulnerabilities throughout the entire development life cycle. By enforcing application security measures, you are able to ensure that weaknesses and vulnerabilities in your software are identified and dealt with as soon as possible in development before they can become serious security breaches. This also helps to keep the overall costs low and enables you to deliver a secure, reliable product on time.

    AppSec Best Practices

    In order to ensure that your application is secure against security threats and vulnerabilities, you must enforce application security best practices. While you and your team may have application security best practices that are specific to your own process, we recommend that you consider also using these best practices:

    • Conduct an application security risk assessment to effectively identify potential security vulnerabilities and weaknesses.
    • Eliminate—or, if elimination is not possible, mitigate—the security vulnerabilities and weaknesses that were identified in the risk assessment.
    • Examine open source and third-party software for security vulnerabilities. Properly address any weaknesses that your examination may have uncovered.
    • Use AppSec tools such as SAST and DAST.
    • Provide your team with application security training.

    By adopting the above best practices, you can be assured that you and your team will have a strong application security process.

    AppSec Tools

    As previously mentioned, one of the most effective ways to ensure application security is to use AppSec tools.

    The most common AppSec tools are:

    • SAST: A static application security testing (SAST) tool analyzes your code as it’s being written in order to detect and report weaknesses that can lead to security vulnerabilities.
    • DAST: A dynamic application security testing (DAST) tool enables you to identify security errors, runtime issues and environment-related issues later in the development of your software.

    By using these AppSec tools together, you are able to ensure application security throughout development.

    Important Secure Coding Standards for AppSec

    In order to effectively enforce application security, you should use secure coding standards to efficiently identify, prevent and eliminate software vulnerabilities.

    The most important coding standards for application security include:

    • CERT
    • CWE
    • DISA STIG
    • OWASP
    • ISO/IEC TS 17961

    A static code analyzer should be used early in development to effectively enforce coding standards to ensure effective application security.

    To read more, please visit: https://www.perforce.com/blog/kw/what-is-appsec

  • Shifting Left and Static Code Analysis with Perforce

    Shifting Left and Static Code Analysis with Perforce

    Perforce Product Manager Stuart Foster, and Evangelist Steve Howard, join Mitch Ashley to discuss the importance of creating security software from the beginning of the development process. We discuss shift left, SAST, source code scanning and other pursuits towards this goal.

    The video is immediately below, followed by the transcript of the conversation. Enjoy!

    Transcript

    Mitch Ashley: I’m pleased to be joined by Stuart Foster, who’s product manager with Perforce, and also Steve Howard, who is static code analysis evangelist, both with Perforce. Welcome, gentlemen.

    Stuart Foster: Hey, Mitch, how are you doing?

    Ashley: Very good. How about if we—let’s start off with just a little bit of an overview of Perforce, and then, Steve, why don’t you do that and also tell us a little bit about yourself, and then we’ll toss it over to you, Stuart, to give you introduction.

    Steve Howard: Right, yeah. Well, here at Perforce, really, our role as we see it is to help developers write better code more efficiently and more quickly. So, these days, we tend to talk about DevOps and the whole idea of developer operations and how they put that code together, how it’s constructed, how it’s managed, how we control the processes around it as well, of course. There’s more and more regulation, it seems, these days in software development and we’re making that whole process from start to finish, of writing code to delivering it, that whole cycle. It’s hopefully being made easier, more comfortable for our developers that use the products.

    So, that’s really where Perforce sits, and we think of that is really enterprise DevOps, and doing it at scale in large scale organizations.

    So, my role, really, is specific on the Static Code side or Static Code security testing side, SaaS tools, if you will, trying to make sure that that piece of writing the code, actually developers writing the code itself is done to the highest possible standard from both the security and the quality perspective and also, at the same time, getting maximum productivity from our development teams.

    Ashley: Wonderful. Stuart, introduce yourself?

    Foster: Yeah, absolutely. I’m Stuart Foster. I’m the Product Manager or Perforce’s Static Analysis products, both Klocwork and Helix QAC. So, I work with Steve, he’s kinda my partner in crime, amongst a number of other sales engineers and developers and everything, and we’re just out to produce a really solid static application security testing tool.

    Ashley: Excellent. Well, one of the great things about talking with you both is, since you have products in market, you talk to a lot of customers, especially in an evangelist role, too, Steve. It really helps us kinda get an idea of where the state of security is in applications, what people are doing today. The whole idea of shift left, I think, has evolved a great deal. I think when I first heard it was “move left in the workflow.” And then it became, “Well, move the when the security people get involved.” And you’ve really taken it much farther than that to really thinking about how we start writing secure code.

    Maybe one of you could kinda give us an idea of where you think we are as a community on getting to that point of when the code’s written, it’s written securely.

    Foster: Yeah, so, I mean, from my perspective, you know, you kind of look historically at people using the term shift left and, you know, from our perspective, that would’ve been, you know, doing some sort of code analysis on a server and then moving that left in terms of the software development life cycle into the developer’s IDEs.

    What you see nowadays is that, you know, historically, a lot of those responsibilities would’ve been siloed. You’d have a security team, a QA team, various other teams that, in many ways, because they’re siloed and in different stages of the process, you’d run into kind of bottlenecks. What you’re seeing a lot more with the concept of DevOps, DevSecOps, a lot of development teams themselves are becoming owners completely of the code that they write. And what I mean by owners is that, you know, they are writing unit tests, they’re writing more functional tests, they are ensuring that it’s part of their responsibility that the code is secure. 

    So, that’s a shift left, but then you have to think how developers work—they’re working in IDEs, they have their own CI/CD pipelines, they may be using cloud services, various containers that are all getting spun up and broken down. So, it’s not just, to me, shift left any more, it’s analysis anywhere. It’s basically having something that can work anywhere in a workflow, right? And in this sense, you know, the Security teams still exist, the Quality Assurance teams still exist, but what it really is, is a culture of security collaboration that are coming together, right?

    Steve, I think you may have a little bit of a perspective on this, too.

    Ashley: Yeah, I’m interested in your from the field perspective, too.

    Howard: [Laughter] Yeah, no, it’s—well, it’s exactly that. I think it’s a really good point that no, we’re not just talking about moving to the desktops, we are talking shifting left throughout the whole cycle. I think that is a key point. And it is really an opportunity using tools like ours in Static Analysis security testing, it’s about being able to enforce the requirements and the needs from that expert security team where there were bottlenecks previously, trying to put that into rules and regulations that we can then push down to the development tasks and processes that are to the left of that kinda final sign-off.

    So, yeah, that—in that form, very much, I’d say it’s shift left, and it’s about that optimized process now where we can be doing that checking all of the time. So, it’s making sure we’re continuously compliant to those security requirements or quality requirements, as the case may be, yeah.

    Ashley: You know, it’s interesting, we talk about the workflow and we think about the whole tool chain and pipeline, but if you really break it down into much more granular pieces, developers are working on a linear piece of development, right? They’re in multiple places jumping back and forth, solving bugs, adding features, developing new capability—whatever it might be. So, the ability to concentrate on any one aspect of an application, sometimes, is not even possible, right?

    So, you need an environment where you’re aided in how you write and create secure code as well as think about writing secure code. You agree with that?

    Howard: Yeah, absolutely. I think that’s the point. We’re trying to make sure that all of those pieces that they’re working on at different times and, you know, our colleagues in the Version Control System team know this very well, but obviously, there are tens or hundreds of branches running in parallel, as you’re sort of saying, and developers are jumping between, you know, fixing problems on the current release, maybe, and then carrying back on with their feature work for the next release as well. 

    And all this time to try and manage what security requirements each one of those had or quality requirements as well would be a really nightmare without sort of tooling and regulation around that, around the whole process, which is a significant part of developer operations as a whole, the idea of automating a lot of that and building it into the system. So, I think it’s just enforcing that with making sure we’re adding all of the extra pieces that we can also include in those processes.

    Foster: And also, if you think about those developers, too, they’re experts in their fields or experts on some of the functionality that they’re developing, but they’re not also necessarily experts as a security team might be, right? So, part of the trick, too, is to offer kinda help, knowledge, learning via the tool set so that, you know, the developers can keep the velocity up and develop to those standards more easily. 

    And I think Steve mentioned a little bit of a buzzword that kinda we like to think about is, it’s continuous compliance, right? It’s having this throughout the process and enforcing it and continuously monitoring, remediating, fixing, and reporting that become important for these processes to run really cleanly.

    Ashley: You know, it’s interesting, there was—kinda stepping back in time, and again, I think about the myth of developers don’t wanna, don’t care about writing secure code. Well, of course, they do. They don’t wanna write insecure, vulnerable code. But I think there’s a period where we thought training was—you know, let’s teach them about how to avoid writing code with vulnerabilities in it.

    But when you talk about a continuous governance environment, you’re kinda talking about a whole layer of things, right? It’s from the person doing the work to the environment that it’s being checked in and integrated and being tested into the workflow, and then really, the data, the information about that, that’s happening on a continuous, ongoing basis. And that’s really your data set for producing the compliance information, right? We don’t have to go ask you or check your code, it’s already been done, it’s done every step of the way all the time, and here’s the evidence of it, and here’s what we learned from it and here’s where we’re doing well and here’s maybe where we can improve. 

    That’s how I think of continuous compliance. Yes, it shows up in a report down the road, but it’s continuous, because we have all that data.

    Howard: Yeah, I think that’s a really important point from the efficiency as well. I mean, the Security team or the Development Management that want to know when this product or project will shift obviously need to know where they are relative to that compliance requirement. And if we can keep it compliant from day one, we don’t ever have that risk of building up technical debt at the end of the process that we then have to solve, and I think that’s a really important evolution that we’ve seen over the last few years, that we have that knowledge to hand immediately at our fingertips, as you say. So, that’s a really important piece.

    And the other point you made there about the developer education, I think, again—yes, you can teach developers and I know myself, in the past, I’ve learned the right way to do things, wrong way to do things, but there’s nothing quite as good as actually showing the examples of when things are potentially risky within the code you are writing, because you really understand, at that point, what you’re writing and how this could then be a problem, and it is the classic on the job experience that you really want for a perfect education, almost.

    Ashley: Let’s take—I’d love to hear your kinda definition or how you describe Static Code Analysis SaaS to people about, if you’re embracing that, what does that mean to a development team, to a software project team?

    Howard: I think from my perspective, it’s the idea of having an automated code reviewer, almost, looking at the work you’re doing in a fairly pleasant and passive way. [Laughter] Not being critical in any way, shape, or form as well. So, from a cultural point of view, I think the developers perhaps accept it more when it’s from a machine rather than a colleague that perhaps is picking holes in the code they’re writing, which is another good point about having a computer do that initial check.

    But yes, it’s like having that guard at the end of the process, and then we often joked historically about the value of the tools and saying, “Well, you know, if you had two developers that were both going for the job, you know, you’re advertising for a new development role, and one of those developers is, you know, the cost of the license is more, but they never make a mistake in the code, they check in clean, compliant code with every commit, whereas the other developer, they both have the same experience, they’re both writing good code, but the other one could make mistakes and could check in, potentially, security vulnerabilities. Which one would you pick as a manager?” That’s quite an interesting way of looking at it, but of course, you would always want to have that assurance that, essentially, it’s clean code from day one.

    Foster: Yeah, and also, you know, in terms of the perspective, Steve talked a little bit about the developer perspective or the hiring perspective. From the business perspective, you have to think about the costs of reputation, lives, revenue, anything of a product being in the field and discovering an issue. You know, the costs to fix a bug exponentially gets more expensive as you go further down the software life cycle, right? So, it’s cheapest to fix it then and there, right at the start. And, you know, in terms of kind of pain points that the software is trying to fix is, you know, providing that knowledge, providing that quick remediation as developers are working, ensuring the velocity stays up, ensuring that the continuous compliance enforcement throughout the process means that there’s not a heavy lifting of work later in the process, because you know, you weren’t reaching compliance requirements. 

    You know, the ease of using the software however a developer wants to work, it’s all about velocity, you know? And in terms of the business having that oversight and understand, you know, what are our risks, and how soon are we gonna be able to ship this product? Because, you know, we know with many products, the faster to market you get, you know, you have that first mover advantage, and that’s what’s needed in this fast-paced software market.

    Ashley: Well, that’s very tough to recovery from reputation damage and quality issues or perceived quality issues around your products, too.

    You know, one of the ways that I explain it to folks outside of being a developer or within the security world is, it’s kinda like taking your spell check of a document and adding in the grammar checking—so, this is the higher order, more complex, specific things around grammar. In this case, it’s around security and helping you as you’re developing or creating code, right, make sure that you do it the best way, you know? Avoid introducing security issues.

    I know that’s a gross oversimplification, so don’t worry, I’m not saying Perforce is like a grammar checker. [Laughter] But that is sort of a non-technical way of describing what we’re doing. I mean, we want it to be that natural, as part of the process.

    Howard: Yeah, absolutely. And I think that’s very true. I think, you know, we’ve seen the evolution of Static Analysis tools very much in the same way we’ve seen the evolution of things like the Microsoft Word, you know, spell checker to grammar checker and so on, and it’s kind of evolved to be more and more all of the time, you know, of the systems similarly.

    But on top of that, there’s also the opportunity, then, to, what we find quite interesting is to write your own checkers and rules that are specific to your application. So, we can find in some places where there have been security problems in a certain application for some special reason—not necessarily related to the constructs of the code, as most of the coding standards check, but something that’s specific to the project because of the way the project has designed all the code, and that project interacts with outside external interfaces. 

    And it has been interesting to work with customers in some cases. I worked with very large telecom customer on one occasion and he said, “Well, you know, we have this translation module between sort of the application and the platform, and nothing should ever, you know, go direct between the two unless they’re going through this one piece in the middle.” And it’s kind of the golden rule we’ve taught to all the developers from day one and nobody will ever break this rule.

    So, you know, obviously, I was slightly challenged by this and said, “Well, it’d be nice to check the rule. Let’s put that enforcement in just to see if we can, you know, use a custom rule to see if there are any cases and, of course, as you say, it should be clean.” And obviously, you know, a couple of hours later, once the analysis is run, it’s a very big system, we found a couple of cases—only a couple, but there were a couple of cases where exactly what they said should never, ever, ever happen for the security of the entire system, it happened. 

    And so, we were able to then remediate those problems and keep that rule in for future development, and of course, it will always be enforced. So, that was a really interesting case where there was also that, where you have something specific, it’s not just generic grammar issues, if you will, or spelling issues, but something very specific to that document.

    Ashley: Mm-hmm.

    Foster: Yeah, you can imagine some of these things coming out of requirements or an internal coding standard or things that a Development team might be following and be able to enforce these. Especially when you start looking at legacy code, giant monoliths, you know, that have been around for 5, 10, 15, 20 years, decades, you know, and you don’t have those original people who are developing, right?

    So, you know, it’s—we sometimes think of our tool also as, you know, kind of like a quality assurance on a product or a code base that, you know, it’s legacy and all the new people have no idea how to use it, but you need to expand on it, you need to develop it, because it’s valuable IP, and how do you manage developing new functionality and moving forward when, you know, it could be as brittle as a glass house, right?

    So, you know, that’s the other benefit you get out of being able to enforce and write your own standards, I’ll call them, and rules, yeah.

    Howard: Another classic case there, Mitch, is—and you’re well aware of this as well from the field is, this system was never intended to be connected to the Internet, you know? This was something that—

    Ashley: [Laughter] You’re guaranteed it will be, then.

    Howard: Yeah. [Laughter] It was an embedded system that was entirely supposed to run in an embedded environment with no connection to an outside world at all, and all of a sudden, you know, it or something around it that’s connecting to it is now connecting to the outside world and there’s open attack interfaces, and now we have to make sure that they’re not gonna compromise the original legacy code base.

    Ashley: Mm-hmm. Yeah, there’s just sort of the rule of unintended uses always occur, right? The thing we don’t want to happen is usually what happens. [Laughter] So, yeah, the demo becomes the production system is another great example.

    I’m really interested in your perspective on where you think we are. If I made an analogy to the network security world, the best time to be a network equipment or network security salesperson is the day of or the day after a compromise, and automatically, you’ve got budget and we need to solve this problem. I mean, I think we’re well past that in most cases, but where are we in the software world? Do you see this as a, it’s just a natural thing, “Okay, what’s our SaaS strategy, how are we gonna be doing security within the application, what tools should we use for that?” Or is it something where you have to mature to a certain point or have experienced some issues before you’re really gonna take it seriously? 

    Where are development—and I’m asking for a generalization I know, but what’s your sense of where people are today?

    Foster: I’d say, you know, in general, it seems as though most people don’t take these kinds of things seriously until it bites them. I think, you know, there’s some kind of safety feelings of some types of products that you can use where, you know, you find out about a security vulnerability or intrusion and you’re using a piece of software that basically just tells you that, you know, the barn doors have been opened and all your horses are gone, right? But that’s too late in the process. I think we all need to understand that, right?

    So, the point of dealing with it sooner and using tools like security application and security testing tools like Klocwork or QAC is that, you know, you’re trying to build the risk reduction, the known unknowns that you can at least deal with sooner, right? So that, you find out later, in the worst case, that the doors were open, but, you know, nothing happened, you still have your horses, because the stables didn’t open at the same time or whatever, right? Just to make a kind of analogy to it, there.

    Howard: Yeah, I think in the—obviously, we do a lot of work in the embedded space, and in that area, having seen it over the last 10, 15 years, I think, you know, there was a time where we were educating people a lot more about what it was, you know, what it was that we could do with Static Analysis to actually find some of these problems. Whereas I think—and there’s a lot more awareness now of the risks in the security field and, obviously, what Static Analysis can do to help. So, most people are starting to think about it if they’ve not already got it built in.

    So, I’d say it is becoming more of an expected insurance policy against those kind of things within the tool environments. And obviously, the other kind of driving force there is the regulation. So, we’re starting to see standards themselves creeping into the market like the new ISO 21434 standard for automotive, for example, where they’re actually going to require some level of looking at the security of the system and making sure that we’ve done some of those things correctly and, you know, probably that will include what we expect it to include, some level of Static Analysis and coding standards and so on and so forth.

    So, that stuff is really becoming almost regulated into the process just like functional safety regulation has been in that process from the beginning.

    Ashley: Definitely.

    Foster: Yeah, you’d imagine—

    Ashley: Sorry, go ahead.

    Foster: I was gonna say, just on that topic there about cyber security for automotive, you think about it, the cars are effectively rolling entertainment systems, right? So, there’s a lot of new kind of vectors for attack, right? An insecure Bluetooth module inside a car and its infotainment system that is also connected to the bus controller that’s driving all the data from every sensor on the car that’s controlling your fly by wire driving and your fly by wire steering and all those things, right? It’s very important—very important.

    Ashley: And usually, you have, I believe, you know, both cars and trucks that have starters can start by Bluetooth as one of the mechanisms. So, yeah, you have potentially the same attack vector, you need to be able to isolate that, and now you’re into the function of the engine versus the entertainment system, and there’s a lot of work going in, I know, to the automotive systems. They’re very complex. I mean, just as complex as many, you know, many business applications—maybe even more so because they’re integrated from so many different suppliers, and they are, of course, largely based on, built on embedded systems.

    It seems like embedded systems, though, are much more accepting of an update process, of keeping the software current and requiring some way of being able to update software in an embedded system or maybe making it an automatic process so it’s kind of touchless. Is that your experience as well?

    Howard: Yeah, I think so. I think that is coming into many systems now. I mean, there are certain manufacturers driving that kind of process—automotive, for example, is a prime case. And it is interesting, because if you go back 10 years, that just was never even considered. You know, once you kind of flashed that system, it was staying as it was until you climbed up the mobile phone master or whatever it was that the embedded system was doing and flashed it again with the latest version. So, yeah, it is, the over the air updates is creeping in, and that will lead us to a more continuous delivery type architecture with the delivery of the software as well, that we’ll be able to go to that.

    So, yeah, it’s gonna be an interesting time. And as part of that, I guess now the focus has moved slightly from the cost of fixing an issue out in the wild to just, we don’t want to have the issue because of the potential impacts on having that issue even for a day, you know? [Laughter] The idea that a car might be possible to take control of from an external source, for example.

    Foster: Yeah, and I think you’re seeing a lot more emphasis on the security around a lot of these embedded systems because a lot of them are so, you know, requirements driven, compliance driven. They have ISO requirements that are needed to be validated by external bodies to make sure that these things are safe to use, because you know, a lot of our infrastructure is built on the backs of these things, that they’re, in some ways, leading the charge of seriousness for these reasons, right?

    Ashley: Mm-hmm. And it seems, also, that industries like, I mean, we were talking about the automotive industry, are putting together their own standards, I think in part of fear out of, “We don’t want government standards to dictate to us, we’d rather us solve the problem, you know, industry solve it” in a way that they’re more accepting and flexible to them. But do you see more regulation coming at a kinda geographical country, government level? Is more of that happening? You talk about ISO standards, of course, being more industry.

    Foster: Yeah, I’d say so [Cross talk]—

    Ashley: You see it happening? Like, our privacy standards, now we’re talking about software security standards?

    Howard: [Laughter] Well, yes, there is that as well. Perhaps in the European level, for example, of something we see on this side, but yeah, mostly, it’s industry standards, from what I can tell that we’re experiencing and seeing come downstream at the moment.

    Ashley: Mm-hmm. [Cross talk]

    Foster: Yeah, I think it depends on the level of kind of sensitivity of the data. So, you do see requirements as they relate to finance and, like, PCI, DSS, and things like that. You see security in terms of—I’m running a blank, here, but they typically come from when the data is so sensitive, you know, the U.S. government has their STIGs, DISA STIG rules.

    Ashley: Mm-hmm.

    Foster: So, it tends to come down from the level of sensitivity. I wouldn’t be surprised if we do start seeing more requirements, perhaps, for public data, but right now, we have things like the HIPAA compliance and things like that, as they relate to very, very sensitive data.

    Ashley: Yeah, the defense industry is also a good one to start to drive standards, too, and I know they’re doing a lot in security.

    So, just to change, shift focus here, we have a few minutes left. We were talking earlier about where people are in their maturity level of adopting SaaS and writing more secure software using those kinds of tools. If you were someone leading a project, maybe an architect or a lead developer or somewhere in the management chain that said, “You know what, we’re almost there, I just need to do a little bit more convincing, or I need something else to help my organization get there to see why we need to do this, and I’d like to do it before we have a major incident”—what’s your best suggestion for kinda doing that? I don’t know if it’s internally selling or if it’s demonstrating the value of it or how do you see people successfully getting the organization to begin to support adopting it?

    Howard: Hmm. I think that’s a tough question, just because there’s so many industries and so many different kind of topics of particular interest, it always helps to have experience of a well-publicized kind of issue [Laughter] that’s gone out into the—

    Ashley: “We don’t wanna be like those people.”

    Howard: Exactly, yeah. That always helps drive things a little bit when you’ve got something tangible to say, “We don’t want to end up there.” I think, again, the regulation piece is where I see a lot of that being driven. You know, the industry bodies are actually saying, “As a whole, the industry doesn’t want to end up there. That’s not somewhere we can afford to be, and so let’s try and make sure we get this right from day one” and that trickles down into individual projects and so on. [Dogs barking]

    Ashley: Well, speaking of dogs [Laughter]—okay, hold on.

    Howard: Okay. Yeah, so, that’s really where we’re—

    Ashley: Okay, just start your answer again.

    Howard: Yeah, so, that’s really where we’re seeing it, predominantly, from the—you know, first of all, we don’t want a case where there is an incident, because, you know, if we can  use that as a tangible case and say, “We don’t wanna be like those guys, because that didn’t end well for them.” So, that’s, obviously, always a good driving force. But then it’s regulation from the perspective of the industry bodies themselves getting together and saying, “We really can’t afford for this kind of thing to happen, and we want to make sure that, you know, across the industry, we start to follow a best practice that’s gonna do our very best to prevent that,” I guess, is a good way of describing it.

    Ashley: It seems this is also an area where security team CISOs can be a real colleague asset for making the case to the rest of the organization, because if you’re _____ on the software team, you have one set of justifications or definitions for why you need that. Another is, there are corporate—you know, the CISO is trying to accomplish these goals, these things with the organization. And it’s always easier to fit your objectives within a larger objective and get that supported and get funding—that kinda thing. So, that’s another suggestion I would throw out there, too, that also helps folks—and plus, it brings security and software teams closer together.

    Howard: Yeah. [Cross talk] Sorry.

    Foster: Yeah. I think we do see—we do see, we do have, you know, security evangelists that are, as you just said, who are championing it, right? And when we talk to those people and we go over Static Analysis with them and this is the security focus, right? It comes down to, you know, being able to help understand their size of team, what kind of current development practices they have, and what that means and how you can deploy, roll out the tools and, you know, not slow down that velocity, because that’s always the goal. Don’t slow down the velocity, but add more value. 

    So, that’s what we try to help them with, help them understand. And also, you know, help—sometimes, you know, Steve is sitting with these people and we almost help them mature in their software development process to, you know, move from a couple guys who are just doing nightlies and they have no version control, they’re not using quality gates, they have no type of automated pipelines to setting them up so that they can scale their development groups, they can speed up their testing, their development processes, and that all comes out of engaging with vendors like us.

    Ashley: Great. Well, gentlemen, this was a lot of fun. I really enjoy talking security and creating secure applications and, you know, it’s something that I think everybody wants to improve at to different levels and degrees, and hopefully, before those bad things happen. It’s always better to do it before, but if you have to do it after, you do. Maybe sometimes that’s what it takes.

    So, it’s been great talking with you. Again, this is Stuart Foster, who is Project Manager with Perforce—thank you, Stuart—and Steve Howard, Static Code Analysis Evangelist with Perforce as well. Take care, gentlemen.

    Foster: Great, thank you.

    Howard: Thanks, Mitch.

  • Integrating Security in the Development Process With DevSecOps

    Integrating Security in the Development Process With DevSecOps

    Occasionally, it’s worthwhile to reflect on how we develop and deliver software during times of rapid change and significant disruption. In those moments of reflection, we learn from the exciting trends and changes that are taking place. Recently I had the opportunity to commiserate with two technical thought leaders at Perforce: Stuart Foster, product manager, and Steve Howard, static code analysis evangelist.

    The disruption caused by COVID-19 goes much deeper than just the rapid shift to work-from-home. Development teams are being asked to keep up developer velocity, while the organization as a whole accelerates digital transformation projects, shifting priorities and emphasizing investments needed to successfully navigate difficult and uncertain economic and market conditions.

    In our conversation, we note how investments already made in shifting to the cloud, remote and cloud-based development, automated testing and pipeline automation and security tools are helping organizations today. We also explore how current conditions influence product roadmaps, causing software teams to take a holistic look at their development processes and tools, and organizations to rethink how to take their software delivery capability to the next level.

    Stuart and Steve share their software best practices on collaboration, automation, security, standardization and more.

    Explore our conversation in more depth by viewing the video and transcript below.

    Transcript

    Mitch Ashley: Well, I’m happy to be joined by Stuart Foster, who’s product manager with Perforce, and Steve Howard, static code analysis evangelist, and I think a lot of other things, too—does a lot with Perforce. So, welcome, gentlemen—good to be talking to you today.

    Stuart Foster: Thanks, Mitch.

    Steve Howard: Hello.

    Ashley: You know, we’re talking about—you know, Perforce does a lot of things, and I think we’re just kind of focusing on what maybe some of the current conditions, current best practices are. There’s a lot happening right now in everybody’s world—a lot of change, a lot of disruption.

    But before we get to that, could I have you both introduce yourselves? Maybe Stuart, would you start first?

    Foster: Yeah. Hi, everybody, I’m Stuart Foster, I’m Perforce’s product manager for our static code analysis products.

    Ashley: Great—Steve?

    Howard: Yeah, and I’m—well, I have, as you say, many jobs and roles within the organization, but primarily focusing on the evangelism around using static code analysis for both of our products, Klocwork and QAC, here at Perforce, yeah.

    Ashley: If you’re working with developers, you gotta be doing evangelism, right?

    Howard: Yeah. [Laughter] 

    Ashley: They expect you to give them support, and be talking to them, in a different kind of way. Tell us—would one of you tell us a little bit about Perforce and what all you all do?

    Howard: Yeah, sure—well, I’ll take that. So, Perforce is an organization, obviously as, you know, originally comes out of the version control software. But really, it’s about developer tools and how we can help make the developer’s life easier in the day to day tasks. So, whether that be trying to prove compliance to standards or just trying to get the stuff out the door in the first place—anything that we can do to help make that process smooth and reliable is kind of where we are. And, you know, these days, that has a bit of a—a buzzword, if you will, around the DevOps tooling ideas, but essentially, it’s developer tools and making their life more comfortable.

    Ashley: That’s great, because you all fit into a number of places in the sort of tool chain, pipeline, workflow process across the development life cycle.

    Howard: That’s right, yeah.

    Ashley: So, that’s awesome. Well, let’s get into this. I’m really curious about what you’re finding in market, and one of the things we like to do when I’m talking with experts like yourself is, let me just try to share some of the things that we’ve experienced within the past, but also kinda recently that it’s happening, because we’re all dealing with economic change, disruption, COVID, work from home, all of those kind of things, but you know, we’ve done some research at my company and there’s a lot—of course, a great, great emphasis on acceleration of digital strategies and, of course, that puts a lot of pressure and emphasis and people are betting money on software being the answer to helping them implement their strategies.

    Are you seeing the same kind of thing, that acceleration of digital transformation and software—elevation of software projects?

    Foster: Yeah. We’re seeing that across the board, even in our own company here. You know, a lot of us have transitioned to work from home, and then you have to start thinking about the considerations for that, right? 

    And what we’re finding ourselves and working with our customers is, a lot of people are shifting more technological tools, right, to be able to better produce workflows and code reviews, how to—working from home, security, right? How secure are your remote development work stations? How is security being built into your software and your workflow? So, tools are being used across the board for that. Just being able to rely on a piece of software versus in-office workflow has become more and more important. And amongst all that, then there’s the goal to, you know, keep development velocity up, which could be a challenge when working from home, right? So, we’re seeing a lot more DevOps automation of, you know , a lot of workflow process and things like that.

    Ashley: Yeah, there’s no more popping over the edge of the cube or to the table next to you, right? Somebody sitting there at the café, in the office, or down the street. It’s a fully digital world, right? You’re not sitting with people very often.

    Foster: Yeah, we’re relying on Slack, we’re relying on Slack calls, Zoom videos, everything to just stay in touch and work and collaborate with one another, yeah.

    Ashley: Steve—yeah.

    Howard: But I think that’s where—yeah, so, I was gonna say, I think that’s where those centralized processes that we’ve kind of all been working towards, luckily, for the last few years, are really gonna pay off. Because how do we not have that? If you imagine how things were maybe five years ago, it would’ve been a much bigger transition to get to where we are now, whereas it was almost like most of our organization was kind of ready to go. We were already there, just—you could call foresightful, but really, it was a little bit of chance, I think. Yeah, those processes have held things together remarkably well, and we’re very lucky for it.

    Ashley: You know, nobody would wish for something like COVID or a pandemic on any of us, but if you look back, you know, I think back when we were virtualizing things and developers were starting to be able to just create a fully self-contained environment to develop on their laptop—I saw people working on planes, right? First time I saw somebody writing code on a plane—that’s awesome.

    But so many things, and then of course, adding the cloud and all the services and software and tool chains and pipelines that we can create now, it—I mean, I think we’re lucky, if you were gonna have something like this happen, now is the time where we can actually continue to be productive, and put more emphasis or pressure on ourselves to deliver software. Do you agree?

    Howard: Yeah.

    Foster: Yeah, absolutely.

    Howard: Yeah—sorry, Stuart.

    Foster: [Laughter] We agreed at the same time, that was great.

    Ashley: [Laughter] 

    Foster: But you’re right, I think, like, some of it—you know, it’s a little bit accidental, but as you mentioned, setting up the development workflow to be able to do it on a laptop, people are shifting their hardware, they’re removing their hardware and going to the cloud, right? So, it’s kind of been like an expansion and a reduction, all—just naturally, but also, you know, you think about DevOps and there’s also, you know, cost savings to be had by not having to have this footprints, not having to worry about these things.

    So, this could be, in some ways, pretty revolutionary or changing for development costs for a lot of companies.

    Ashley: Steve, you were gonna jump in there—anything to add?

    Howard: Yeah, no, exactly the same. I think the fact is that we—you know, a lot of that infrastructure is being built up and the idea of being able to run our development pipelines kind of in a cloud environment or whatever and having that all ready to go just meant that we didn’t have to pick up ginormous work stations. I remember back in my days of developing in aviation software, we used to literally have, you know, Unix boxes stacked up on the side somewhere that we had to go and log in on each one and run our testing for each single one. It’s just unthinkable. It would never have been possible.

    Ashley: That would be insane today. You would never. I mean—

    Howard: Yeah.

    Ashley: – if you have a choice, you would never do that, right? [Laughter] 

    Howard: Well, exactly, and the very fact that, you know, 10 years ago, we still had to do that, how could we have transitioned? It wouldn’t have been possible. And so, it really is testament to how far we’ve really come in 10, 15 years to see where we are with our testing processes, the fact that we can do, you know, 99 percent of it, if not all of it can be done completely with no connection to the physical space.

    Ashley: Mm-hmm.

    Howard: It’s all—and that can even mean, you know, in the cloud completely, so it’s not even within our organization. It’s securely being done off site somewhere in the ether. [Laughter] 

    Ashley: Yeah.

    Howard: And that process is still completely manageable, it’s something we can all see as developers, everyone can get to see where we currently are with that process, you know, what the latest test run gave us across the whole—

    Ashley: I’m really curious—yeah, I’m really curious what your experience in market is. Do you see more people who are kinda doubling down and getting even more serious about their DevOps implementation and taking it to the next level, or do you see more people coming to you that maybe are relatively new to DevOps and are looking for tooling and looking for ways of helping them, you know, not just get started and learn all the problems themselves, experience them themselves, but looking from the experience of a software provider like yourself, or is it a little bit of both?

    Howard: I’d say a little bit of both. I mean, obviously initially, there was such a lot to do already and everyone kind of had no time to really think—understandably, but probably within, you know, since the end of the summer, maybe, things have started to come back and people are actually going, “Well, hang on a minute. We’ve got a process, but now, how can we actually make this a lot easier for ourselves?” and looking to improve that.

    And I think, you know, for a lot of the organizations where, perhaps, doing things off site would never have even been considered. And I think this was to Stuart’s point—that kind of, that’s been forced upon people and it’s almost gonna change the way we develop forever now as a result of that, because we have now, we’ve done it, we’ve experienced that it’s possible, and it’s safe and it’s secure. 

    How can we now make that better and make our lives easier by not having that massive footprint that Stuart was mentioning? We’ve actually got something that’s very, very lean, it’s in the cloud, we’ve got machines when we need them, but not when we don’t need them, and how can we really make that process as efficient as possible from the results side, you know, making sure we’re doing what we’re supposed to be doing as quickly as possible, but also actually trying to reduce our footprint on process and power, for example? You know, the development time that’s involved in that, how can we make that as efficient as possible?

    Foster: Yeah, and I also think what we’re seeing, too, is, you know, our existing customers, they’re doubling down on their tools, you know, because they need to rely on something, right? And that’s also, what it’s done is also, I think, is changing some of the roadmap items that all products are looking at, right? There’s a whole new—not a whole new paradigm, but you know, there’s a little bit more seriousness being taken in terms of some of these features and functionalities of being able to work remote, or the requirements for more cloud usage, right? We’re talking ease of use, we’re talking about things that are, you know, related to workflows to make working in these conditions—not just in these conditions. Assuming you get back to the office, just more efficient as well.

    Ashley: Mm-hmm.

    Foster: So, we’re seeing that at the same time, too. And then, you know, from the perspective of new customers coming in, they’re almost expecting these things to already be there, right? Because they’ve run up to these problems as COVID has created and they’re trying to find the solutions that are gonna be kinda turnkey out of the box.

    And also, I’ve done, I’ve been talking with various analysts related to our product, but it seems as though the analyst community itself is, they’re seeing the requirement for, you know, ease of use in DevOps becoming more important as well at the same time.

    Ashley: Mm-hmm. I think that may be also, in part, the expansion of DevOps into the organization. They may have had a core group of teams that were really taking the challenge of DevOps and implementing it and now, how does the rest of the organization do the same thing, but accelerate their adoption of it?

    Foster: Yeah, and I think also, a lot of development groups within a single company—you know, you may have a security team, you may have a development team, you may have a LiveOps team—they’re starting to recognize that there are choke points in the development processes.

    Ashley: Mm-hmm.

    Foster: And so, how do you unblock that? How do you make it more easy? How do you offload some of that choke point onto a broader group, right? A lot of the idea of DevOps, DevSecOps, whatever you wanna call it, right, is that developers are owning the code that they produce in more broad ways. That’s writing unit tests, that’s making sure they do the QA on it, right? That’s when they’re, you know, they have to implement the security requirements then and there, right? They need to ensure the traceability is done, right? They have to—they’re taking that into their hands. It’s becoming not so much that there’s a DevOps group that magically handles all this infrastructure, it’s becoming part of each developer’s responsibility as well, right?

    Ashley: Hmm. Interesting. You know, I know, as you scale things out and you adopt new tools, tools do a lot of things for you, but there’s oftentimes, there’s approaches that you need to adapt into your tools, things like what are our coding standards, what are our testing, what level of testing do we do? How do we break it into chunks? When do we do security testing of our code?

    And that’s part of that learning curve to is, how do you adapt a tool set to both what your requirements are, but also, you would like it to kinda take you to the next level. What are some of the things that really can help people kind of propel their expertise in the organization’s ability to deliver software more effectively?

    Howard: Yeah, that’s a really good point. So, one of the things, you mentioned coding standards there, but obviously, you know, those can come from multiple sources, they can be something that’s actually being required by a standard, for example, if it’s in a safety critical, security critical world. It could be something that’s actually demanded by the organization itself—they have their own rules or there’s certain things in any particular project that, if you do things in a certain way would make, you know, it would be dangerous or insecure or something. So, they have some controls, as well, of that.

    And what we do see is, the more that we can get that information out to our developers, for example, the more value that has as well. So, yes, we can help enforce coding standards, for example, with our Static Analysis tools. But that’s only half the story. Enforcement is one thing; actually getting the developers to understand what the problems are as they’re creating them and to have easy access to the help and the quick feedback of those problems makes it much more powerful, because it gives them, (a) you know, all the resources they need to deal with the problem quickly and to not perhaps find it a challenge to have to deal with, but also, they learn. 

    And so, the next piece of code they write doesn’t generally have the problem. So, there’s a developer learning element there as well, which we can control centrally, and then spread out to all of these remote workers working—you know, without that team collaboration that we used to have, we’re still able to do the same things. So, that’s become something that’s really focused people’s minds on the capability there in terms of what that means. And as I say, that applies to security standards that are well known or requirements for quality that we have to work to for a security or safety standard—

    Ashley: Mm-hmm.

    Howard: – but also the company’s own rules.

    Foster: Yeah, and I think, you know, outside of just simply the tools, development teams are, you know, taking a step back and re-evaluating or thinking more about what their software development process is, holistically, right? You know, Steve mentioned there some of the tools, best practices, but you know, you also have to think what kind of, you know, software development methodologies might you be using. You know, sometimes it doesn’t matter whether it’s agile, waterfall, whether you’re using Scrum or Kanban, you know, I think it’s giving people a moment to think about what’s the most important kind of Dev process that is gonna fit this team or how you have to work now, how it fits the businesses. 

    And then implementing processes to ensure the organization, communication, and what systems need to be put into place to help prevent any problems that arise during development and kinda identifying and understanding that. Then you’re picking the tools, you’re building your development workflow, whether it’s in environments, it’s setting up DevOps pipelines to ensure that everything’s followed correctly. It’s the tools, but it’s the process, and that’s changed, too.

    Ashley: That’s interesting. You know, we’ve done some research about the influence that developers have had on the organization, too. Even outside of development teams, you’re seeing DevOps and agile kind of principles, even though they aren’t calling it that—daily standup meetings, shorter intervals of deliverables, more kinda asynchronous communication tools and collaboration kind of tools, which really makes it easier, I think, for the development teams, the product teams—you’re a product manager yourself, Stuart.

    Foster: [Laughter] 

    Ashley: And beyond—operations, security—everyone is kind of forced to work a little bit differently, but also can benefit from what each other knows about how to do that more effectively. And we seem like we’re at this sort of serendipitous time of being able to leverage that, which fits right into the tooling approaches that we can take.

    Foster: Yeah, and you know, when you look at it, like, it always just ends up communication. Whatever the communication is, whether that’s the workflow, whether that’s in-person, whether that’s meeting, whether that’s documentation, it’s all about communication, and that’s true not for just development, but for business, right? Developers working, you know, with other groups—marketing, sales—everything, it’s all communication. It just keeps business running. And that’s kinda the funny kinda perspective that may not necessarily be outright visible by simply saying, “It’s communication.”

    Howard: What’s interesting is, that’s also kinda mirrored in the tooling, because a lot of the work we’ve been doing recently is about how to make sure the tools have all got open interfaces to communicate with the next thing in the pipeline or to feed that data back up to some dashboard that’s gonna be shared with the rest of the team.

    So, yeah, it’s kind of an interesting point, but that also applies with the tooling that we’re trying to build around that.

    Foster: Mm-hmm.

    Ashley: Mm-hmm. A really great point. So, to give you fair warning, I’m gonna ask you your three recommendations on best practices in the current climate, so be thinking about that.

    I was thinking about your comment, Steve, about being able to better integrate tools together and then taking the data from the tool sets, the pipeline of the process that we’re going through and the pipeline of work—there’s so much value in that data that sometimes ends up as exhausts or on the cutting room floor, right, to use two different metaphors. But that information could be extremely valuable, putting it into dashboards, feeding it into continuous improvement processes, shortening the window for getting feedback for, “Here’s a security vulnerability or a coding standard” or some kind of an error that you can fix in minutes instead of days and weeks and sometimes months, right? The security audit at the end of the release is much easier, because you’ve already gone through so much to it. Those can all be things that can help us.

    So, I gave you a little bit of time there to think about your three best practices. I did my best job of stalling that I could. So, who would like to go first? What would you recommend people consider today?

    Foster: Yeah, I’ll go. Just, I want to reinforce that message of,  you know, figuring out how you’re going to work as a development team, develop that communication, right? And that’s using your tools.

    I think in the world of remote work from home, having kind of a common language—again, back to communication—of how, you know, each developer’s system is set up. So, common environments, they should be using as close to the same setups as possible so that, you know, when one of you is running into an issue, it’s easier to get that information across, right? You’re not gonna have to install something obscure because somebody’s using something obscure. You should all be trying to talk and use the same tools so you’re all speaking the same language. That allows you to have that velocity that you could otherwise lose.

    And in this world, too, security hasn’t been more important than ever—security is more important than ever. So, think about securing your Dev processes, developing secure software, it’s gonna be very important. And those are kinda my three.

    Ashley: Okay, great. All good ones. Steve?

    Howard: Yeah, I’d answer—so, my three would be, first of all, to automate; take the process away from the day to day effort of the development teams and organizations around them. So, yeah, that’s the first one.

    Report—so, that’s the communication piece, I guess, but get the information to the right people at the right time and hopefully in the right sort of time window.

    And then shift left. So, then, we make it more efficient. Then we look to where we can try to remove the fat in the process and take away the time that was wasted and try and move it to the right position in that process. So, yeah, those three, in that order. [Laughter] 

    Ashley: Great. Excellent, excellent. I’m curious what you both think will be some of the things that will stay with us, the things that’ll last past a forced work at home, forced work remote. Maybe people are returning to the office, maybe they aren’t. What do you think are some of the things that will stick with us? Because it wasn’t like we were doing this for two weeks and then we’d just go back to the office—this is an extended period, we’re developing new habits, we’re changing how we’re working. Why go back, sometimes, right? What are your thoughts?

    Foster: I think you’re gonna see a lot of these workflows stay around. I think that the reliance on the numerous tools to keep velocity up and reduce and automate are just gonna stick around. You know, you don’t want to be wasting time on trying to get something to work. It’s easier to just simply automate it and get it out of your hands so that, you know, at least from a development perspective, you can just focus on what’s important, which is, you know, coding, the feature, getting the product out the door, right?

    Those are gonna stick around, and I think the tools, over the course of time, are just gonna keep reinforcing and strengthening that kind of automation pipeline.

    Ashley: Good.

    Howard: Yeah, no, and I think, from my perspective, just to add the one small piece there is, the cloudification, essentially, of the processes. So,  I think, you know, people will stop having the premises to host great, big server racks in, and that’s just all gonna move off site, off premise, outside of the organization, for sure, yeah.

    Ashley: Yeah. To kinda add what you both have said, which I think supports your thoughts on this is—you know, as we change to whatever we’re gonna go back to, I don’t think it’s gonna be back to what we were doing. But it’s gonna be a hybrid, right? I can’t imagine everyone shifting back to a different way. It’s—some people are still, maybe even more percentage of our teams are working remotely, never going back into an office, but we may have some that do.

    We’ve broadened the reach across the globe of people that we’re working with, the product and vendor, tool vendors that we’re working with. Those things aren’t gonna change, right? 

    Howard: No. No.

    Ashley: We’re gonna stay doing that. If we’ve found something that works better, you’re gonna stick with it, right? So, you’re gonna stick with—you’re gonna stay in the cloud, push more in the cloud, right? And leverage some of the automation, the processes that you talked about, Stuart.

    Well, this has been really fascinating. Would love to have you both back, have you guys back and we can talk some more about—I’m gonna delve into static code analysis evangelist, your role, Steve, get into some of that, which I know you all have some of your products do and to security and to some other areas within the software pipeline, but this has been really great. I’ve really enjoyed talking with you both.

    Howard: Yeah, it’s been a pleasure.

    Foster: Great. Thanks, Mitch.

    Howard: Bye bye.

    Ashley: You bet. We’ll see you soon.

  • What Is IEC 62443?

    What Is IEC 62443?

    IEC 62443 helps to protect industrial automation and control systems from security breaches. Read on to learn more about the standard.

    What You Need to Know About IEC 62443

    IEC 62443 is a set of security standards for the secure development of Industrial Automation and Control Systems (IACS) that provides a thorough and systematic set of cybersecurity recommendations. The security standard is used to defend industrial networks against cybersecurity vulnerabilities.

    The IEC 62443 Security Levels

    A central part of IEC 62443 are security levels (SL), which are used to assess the cybersecurity risks to each system. An additional benefit of security levels is that they help you to understand how to best address the identified cybersecurity risks. There are five security level values, which range from 0 (the minimum level of risk) to 4 (the maximum level of risk).

    The 7 Security Level Foundational Requirements

    For each security level, there are seven specific foundational requirements that must be met. These requirements help you to ensure that each IACS has the right security and safety safeguards.

    The seven foundational requirements for a security level are:

    1. Identification and Authentication Control
    2. Use Control
    3. System Integrity
    4. Data Confidentiality
    5. Restricted Data Flow
    6. Timely Response to Events
    7. Resource Availability

    In addition, each foundational requirement has multiple conditions that must also be met, depending on the safety level.

    What You Need to Know to Comply with IEC 62443

    An essential part of complying with IEC 62443 is using a static code analysis tool. Static code analysis tools automatically identify vulnerabilities and defects as you code. In addition, IEC 62443 requires that a static analysis tool be used to enforce secure coding standards, such as CWE, CERT, and OWASP. By using secure coding standards, you ensure your software is secure and safeguarded from vulnerabilities.

    To read more, please visit: https://www.perforce.com/blog/kw/what-is-iec-62443

  • SAST vs DAST: What’s the Difference?

    SAST vs DAST: What’s the Difference?

    One of the most effective practices for ensuring that your software is secure and safeguarded against security vulnerabilities is using the right secure coding tools — like SAST and DAST.

    The Key Differences Between SAST and DAST

    Both SAST and DAST are used to find software security vulnerabilities in your code. However, these DevOps tools are used at different times during the development process.

    Here are the key differences between SAST and DAST.

    SAST:

    • White Box Security Testing
    • Source code is required.
    • Vulnerabilities found earlier in development and are less expensive to fix.
    • Unable to identify timing- and environment-related issues.
    • Generally, supports all kinds of software.

    DAST:

    • Black Box Security Testing
    • A running application is required.
    • Vulnerabilities found later in development and are more expensive to fix.
    • Can identify run-time and environment-related issues.

    The Main Advantages of Using SAST Tools

    The main advantages of using SAST tools include the following:

    • SAST tools find coding issues by looking for known vulnerability patterns in internationally recognized coding standards for quality, safety, and security — such as CERT, OWSAP, and CWE.
    • SAST tools detect and fixes defects early in development. This leads to lower costs to fix defects.
    • SAST tools often features a Shift-Left approach, which enables analysis to be done anywhere — including on your desktop and in your CI/CD pipelines.
    • SAST tools are easy to automate, able to effectively scale to your project, and automatically provide the highest levels of code coverage.
    • SAST tools provide fast feedback along with the exact location of vulnerabilities and their cause.

    The Main Advantages of Using DAST Tools

    The main advantages of using DAST tools include the following:

    • DAST tools analyze the entire application as it runs within the full system environment.
    • DAST tools are able to “look inside” your application and dynamically analyze execution logic and live data.
    • DAST tools are language and source code independent.
    • DAST tools check for memory consumption and resource use.
    • DAST tools attempt to break encryption algorithms from outside of your program.
    • DAST tools verify permissions to ensure the isolation of privilege levels.
    • DAST tools check for cross-site scripting, SQL injection, and cookie manipulation.
    • DAST tools test for vulnerabilities in third-party interfaces.
    • DAST tools understand arguments and function calls.
    • DAST tools record application execution for post-mortem test failure analysis.
    • DAST tools catch hard application failures.
    • DAST tools perform unattended script-based dynamic analysis. In order for an effective security program, you will need both a SAST and DAST tool.

    To read more, please visit: https://www.perforce.com/blog/kw/sast-vs-dast

  • Perforce Software Acquires Methodics, Expanding DevOps Portfolio

    Perforce Continues to Grow Platform Already Used by Top Semiconductor Companies 

    MINNEAPOLIS, SAN FRANCISCO, and SANTA MONICA, July 20, 2020 – Perforce Software, Inc. (“Perforce”), a provider of solutions to enterprise teams requiring productivity, visibility, and scale along the development lifecycle, backed by Clearlake Capital Group, L.P. (together with its affiliates, “Clearlake”) and Francisco Partners, today announced it has acquired Methodics Inc. (“Methodics”), a leading provider of intellectual property lifecycle management and traceability solutions for enterprises. The addition of Methodics further distinguishes Perforce in the DevOps market as a solution provider uniquely addressing the needs of some of the largest technology teams in the world facing extreme scale, time to market, and quality imperatives. Terms were not disclosed.

    Perforce and Methodics previously had a strategic partnership in place, providing a fully integrated solution to manage IP from design all the way through production and reuse in the semiconductor industry. Many of the world’s top semiconductor companies already leverage Perforce and Methodics’ solutions for electronic design and data management.

    “The semiconductor and embedded software design markets continue to expand, especially as they serve growing AI, automotive, cloud, and IoT markets,” said Mark Ties, Perforce CEO. “Together with Methodics, Perforce will enable these markets to drive faster time to market, higher quality, greater operational efficiency, and increased security and compliance at scale. We are also excited about the opportunity to extend this joint solution into gaming, automotive, and other industries.”

    “The importance of collaboration between multisite and multi-geographic design teams continues to intensify. Methodics solutions enable critical collaboration while assuring full traceability and reuse of important design assets and their associated metadata,” said Simon Butler, Methodics CEO. “We are excited to join the Perforce team, and we are confident that this acquisition will enable us to meet the needs of the semiconductor and embedded systems markets, as well as gaming, automotive, and beyond.”

    “Maxlinear has been using Perforce Helix and Methodics IP life cycle management solutions for the past few years to increase our productivity and introduce an IP reuse methodology at Maxlinear,” said Paolo Miliozzi, Vice President, SoC Technology at MaxLinear.  “We are looking forward to the solutions that the combined companies will be able to deliver to us moving forward as MaxLinear continues to grow.”

    About Perforce
    Perforce powers innovation at unrivaled scale. With a portfolio of scalable DevOps solutions, we help modern enterprises overcome complex product development challenges by improving productivity, visibility, and security throughout the product lifecycle. Our portfolio includes solutions for Agile planning & ALM, API management, automated mobile & web testing, embeddable analytics, open source support, repository management, static & dynamic code analysis, version control, and more. With over 20,000 customers, Perforce is trusted by the world’s leading brands to drive their business critical technology development. For more information, visit www.perforce.com.

    About Methodics
    Methodics is recognized as the premier provider of IP Lifecycle Management (IPLM) and traceability solutions for the Enterprise. Methodics’ customers benefit from the products’ ability to enable high-performance analog/mixed signal, digital, software, and SOC design collaboration across multi-site and multi-geographic design teams and to track the usage of their important design assets. The company is headquartered in San Francisco, California, and has additional offices and representatives in the U.S., Europe, Israel, China, Taiwan, and Korea.  For more information, visit www.methodics.com.

    About Clearlake

    Clearlake is a leading private investment firm founded in 2006. With a sector-focused approach, the firm seeks to partner with world-class management teams by providing patient, long-term capital to dynamic businesses that can benefit from Clearlake’s operational improvement approach, O.P.S.® The firm’s core target sectors are technology, industrials, and consumer. Clearlake currently has approximately $24 billion of assets under management and its senior investment principals have led or co-led over 200 investments. More information is available at www.clearlake.com.

    About Francisco Partners

    Francisco Partners is a leading global private equity firm that specializes in investments in technology and technology-enabled businesses. Since its launch 20 years ago, Francisco Partners has raised more than $24 billion in committed capital and invested in more than 275 technology companies, making it one of the most active and longstanding investors in the technology industry. The firm invests in opportunities where its deep sectoral knowledge and operational expertise can help companies realize their full potential. For more information on Francisco Partners, please visit www.franciscopartners.com.

     

  • New Perforce Version Control Expert, Brad Hart, to Share Vision for Enterprise-Grade Code Management in Online Event February 12

    Hart has 20 years of experience designing and implementing version control solutions for the enterprise.

    MINNEAPOLIS, FEBRUARY 5, 2019 – Perforce Software, a provider of solutions to enterprise teams requiring productivity, visibility, and scale along the development lifecycle, is excited to announce Brad Hart as the new Chief Technology Officer of Version Control. Customers and prospects who are interested in meeting Hart and learning about his vision for enterprise-grade version control and code management can attend a live webinar on Feb. 12.

    Hart has more than 20 years of experience working with large technology organizations to optimize development pipelines. He specializes in software engineering process, design, and implementation. Hart is a co-founder of AccuRev (acquired by Micro Focus in 2013), and he previously worked as a ClearCase consultant at IBM.

    For Mark Ties, Perforce President and CEO, bringing Hart on board was a strategic decision to strengthen the Company’s well-stacked team of experts. “Hart’s deep experience with version control makes him a natural fit for the position. Our customers rely on us to solve the scalability and performance challenges that come with large-scale product development. We are able to do this because of experts like Brad Hart — leaders who have deep technical expertise, not just in version control, but across the development lifecycle,” Ties says.

    Perforce has historically served large development and DevOps teams with sophisticated version control needs,  but so many large teams out there still face challenges that can be overcome with the right approach.  For Brad, that’s one of the things that makes the position most exciting. “I specifically came to Perforce with the goal of solving these previously unsolvable problems, and to address the needs of the world’s most complex development organizations,” Brad says.

    Sign up for the webinar on the Perforce website.

    About Perforce
    Perforce is a leading provider of enterprise-scale software solutions to technology developers and development operations (“DevOps”) teams requiring productivity, visibility, and scale during all phases of the development lifecycle. Enterprises across the globe rely on its Agile planning and ALM tools, developer collaboration, static code analysis, version control, and repository management solutions as the foundation for successful DevOps at scale. Perforce is trusted by the world’s most innovative brands, including NVIDIA, Pixar, Scania, Ubisoft, and VMware. Perforce has offices in Minneapolis, MN, Alameda, CA, Mason, OH, Boston, MA, the United Kingdom, Finland, Sweden, Germany, India, and Australia, and sales partners around the globe. For more information, please visit www.perforce.com.

  • Clearlake Capital-Backed Perforce Software to Acquire Rogue Wave Software

    Strategic acquisition expands Perforce’s DevOps solutions portfolio to include developer tools and components that optimize the application development process

    MINNEAPOLIS, MN and SANTA MONICA, CA – January 22, 2019 — Perforce Software (“Perforce”), a global provider of enterprise-grade DevOps-focused software solutions, backed by Clearlake Capital Group, L.P. (together with its affiliates, “Clearlake”), today announced it has reached a definitive agreement to acquire Rogue Wave Software (“Rogue Wave”), a leading independent provider of cross-platform software developer tools and embedded components.

    The combination of Perforce and Rogue Wave delivers a full suite of solutions that measurably improves developer productivity while fueling DevOps at scale. This is the sixth acquisition by Perforce in the last two years since embarking on an aggressive growth strategy to expand its portfolio across the technology development lifecycle. Terms are not being disclosed. The acquisition is expected to close in early February of this year.

    Rogue Wave provides market-leading solutions that help enterprises optimize software development and build, connect, and secure applications while reducing risk. The company is a leading provider for enterprise organizations and has relationships with more than 5,600 customers across industries including financial services, technology, healthcare, government, entertainment, and manufacturing. Rogue Wave is based in Louisville, Colorado and has 16 offices throughout the world.

    “This transformational acquisition further expands our global footprint and broadens our offerings.  Rogue Wave’s software suite strengthens Perforce’s existing static code analysis and automated test offerings, and also adds new capabilities in the areas of dynamic code analysis, API management, project visualization, developer productivity, and embedded analytics,” said Mark Ties, Perforce CEO. “Together with Rogue Wave, Perforce will continue to drive value for enterprises that value scalability, speed, and security.”

    Perforce continues to build out its DevOps-focused software portfolio that uniquely meets the needs of technology development teams that are challenged with multiple dimensions of scale but still must deliver products securely at a rapid pace.

    “The momentum at both Perforce and Rogue Wave is impressive and we look forward to capitalizing on the significant market trends around enterprise DevOps at scale,” added Prashant Mehrotra and Paul Huber of Clearlake. “We are excited to continue to support Mark and the collective management team as they drive consolidation in the industry and increase the breadth of their platform, both organically and inorganically.”

    “Software development is growing increasingly complex, driving the need for platforms and solutions that can help enterprises simplify their applications and shorten cycle times. With continuously evolving customer demands, it has never been more important for enterprises to deliver high-quality products and solutions quickly. Rogue Wave is a software platform of choice for enterprise clients that value stability and security,” said Brian Pierce, Rogue Wave CEO. “Our team and technology are a great fit with Perforce and we look forward to providing our combined customer base with solutions for more of their DevOps needs.”

    Financing for the acquisition was led by Antares Capital with joint lead arrangers Ares Capital Management, AB Private Credit Investors, Barings Finance, PennantPark Investment Advisers, and Varagon Capital Partners. William Blair and Shea & Company acted as financial advisors to Rogue Wave.

    About Perforce

    Perforce is a leading provider of enterprise scale software solutions to technology developers and development operations (“DevOps”) teams requiring productivity, visibility and scale during all phases of the development lifecycle. Enterprises across the globe rely on its agile planning and ALM tools, automated mobile and web testing, developer collaboration, static code analysis, version control and repository management solutions as the foundation for successful DevOps at scale. Perforce is trusted by the world’s most innovative brands, including NVIDIA, Pixar, Scania, Ubisoft, and VMware. For more information, please visit www.perforce.com.

    About Rogue Wave

    Rogue Wave helps thousands of global enterprise customers tackle the hardest and most complex issues in building, connecting, and securing applications. From API management, web and mobile, embeddable analytics, static and dynamic analysis to open source support, the company provides the software essentials to innovate with confidence. More than 2,000 global organizations partner with Rogue Wave to power new opportunities and remove risk from strategic initiatives. For more information about Rogue Wave, visit www.roguewave.com.

    About Clearlake Capital

    Clearlake Capital Group, L.P. is a leading private investment firm founded in 2006. With a sector-focused approach, the firm seeks to partner with world-class management teams by providing patient, long-term capital to dynamic businesses that can benefit from Clearlake’s operational improvement approach, O.P.S.® The firm’s core target sectors are software and technology-enabled services; industrials and energy; and consumer. Clearlake has managed over $8 billion of institutional capital since inception and its senior investment principals have led or co-led over 100 investments. More information is available at www.clearlake.com.

     

  • DevOps Chat: Perforce Acquires Perfecto Mobile

    DevOps Chat: Perforce Acquires Perfecto Mobile

    Consolidation is in the air, as two well-known players in the DevOps space—Perforce and Perfecto Mobile—are joining forces. Perforce has announced its intent to acquire Perfecto Mobile for its mobile and web automation testing technology, which, when combined with Perforce’s existing portfolio, will better enable organizations to achieve continuous testing at scale. It’s a great combination and one I believe will be well-received in the industry.

    Perforce CEO Mark Ties and Perfecto Mobile COE Eran Yaniv spoke with me about the acquisition and its potential impact on the testing space as a whole, and Perforce’s plans for more acquisitions down the road.

    As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

    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. The news involves the merger – acquisitions and merger of Perforce and Perfecto Mobile, two pretty well-known brands in the DevOps space. News just came out this morning and we have with us the CEO of Perforce, Mark Ties, as well as the CEO of Perfecto, Eran Yaniv, and if I mispronounced anyone’s name I do apologize in advance. But gentlemen, welcome.

    Eran Yaniv: Thank you.

    Mark Ties: Thank you very much. Great to be here.

    Shimel: Thank you. So guys, you know, I was lucky enough to sell a company or two in my time, and then one of the companies I helped found we did about 30 acquisitions in 36 months so it was almost one a month. It was a little crazy. But, you know, a wise man much older, wiser, and wealthier than myself told me that any time you can, you know, found a company and someone buys it, whether it be a merger, acquisition, whatever you want to call it, but you find a suitor who’s willing to pay significant money, it is a – it is something to be proud of, right? It’s an accomplishment. So congratulations to you,  Eran. You know, any time you can CEO a company that has some sort of liquidity in that, it’s a good thing. So congratulations. And Mark –

    Yaniv: Thank you very much.

    Shimel: – on the other hand – thank – you’re welcome. Mark, on the other hand, any time you could, you know, take the helm of a company that’s out here and getting entrepreneurs to actually, you know, trust you with their baby, so to speak, and it shows a level of trust that you will do right by them and right by their customers, so congratulations to you as well.

    Ties: Thank you.

    Shimel: Let’s dive in a little bit though, Mark. What kind of drove this? What drove the acquisition here or the merger?

    Ties: Since we acquired the management team at Perforce, acquired Perforce a couple years ago, and we’ve been on a journey here to create what we believe will be a strong DevOps player in numerous assets of the space, and as of recently we’ve been very focused on the testing environment witnessed by our earlier-in-the-year acquisition of PRQA and Static Code Analysis and now Perfecto, so Eran and I have been chatting for a number of months here and we’re just, you know, absolutely excited, ecstatic, that we’ve gotten the opportunity here to partner with his cofounder Yoram and himself and the rest of the Perfecto team to bring their capabilities in web and mobile testing into the Perforce family, so that’s really what drove it, is our focus on testing and then their industry-leading capabilities.

    Shimel: Sure. Eran, what about you? You know, Perfecto Mobile – I mean I’ve had devopsy.kinsta.cloud now for four and a half years with publishing. Perfecto’s always been on the scene. We’ve had the pleasure of doing webinars and reports and conferences, sponsorships with Perfecto. What was the, you know, impetus to do this deal now?

    Yaniv: Well we were kind of discussing this internally for a while now, and when we look at the market we believe because the market is evolving more and more towards implementing DevOps-related processes when there is a requirement with which we call internally a gorilla in the market. The decline of CAs and, you know, IBMs and the HPs of the world is actually opening up – has actually opened up quite a few opportunities and we thought that – we think that the development of a very strong leader in the DevOps market is something that is required, that the market is actually requiring. And so we, you know, were looking around to see what companies are out there that would make sense for us to merge with or acquire or get acquired; something that would create something of a bigger size and a bigger voice in this market.

    And, you know, there were various options but we – you know, I really like this notion Perforce because I think nobody in the market really saw it coming, and for us it’s a very exciting opportunity because the offerings are complementing – even complementing status in terms of the install base, so the opportunity was there to actually make it happen and, you know, it aligns really nicely with what we were thinking about the market, so we went forward.

    Shimel: Absolutely. Well, you know, if I may add my own armchair quarterback –

    Yaniv: I’ve got to say one more – I’ve just got to say one more point that I think is very important, and that is the initial chemistry with the team at Perforce made it a very easy decision.

    Shimel: You know, Eran, on that point I will tell you just this culture is important in DevOps in doing mergers and deals like this. The chemistry of the teams is as important or more important sometimes than even the numbers in the books, right? Because the merger doesn’t end on the day of the merger; it only begins. And, you know, it’s important that you have that in there. If I can offer my two cents as an armchair quarterback, I think what we’re seeing here is also the result of a larger trend in the DevOps space.

    You spoke about CA, which is, you know, now getting acquired by Broadcom and there’s perhaps uncertainty there, the IBMs – you know, certainly while these companies played in the DevOps space they weren’t necessarily perceived leaders in DevOps, in the DevOps space and, you know, when you see a company like GitHub, which started out as a code repository, right – it did open source good – getting purchased for, you know, this $7.5 billion by Microsoft, it wasn’t just as a code repository, obviously. And, you know, just recently in the last two, three, four weeks companies like GitLab, you know, with $100 million raise, $1 billion-plus valuation, last week it was JFrog with a DevOps platform with $165 million raise, over $200 million raised – you would have to assume they’re also over $1 billion – it certainly seems like the time is ripe for size.

    Size matters in DevOps, right? Size and scale matter. And so, Mark – go ahead.

    Yaniv: I was going to say that we are seeing these things actually happening in the market. _____ is making all kinds of –

    Shimel: Sure.

    Yaniv: _____ primarily in the _____ area. The thing that I like about the Perforce Clearlake, if you will, in conversations with – and this is what I really like, is the fact that they are dead serious about what they are doing and their moves are very, very quick and they’re very nimble in their decisions and that’s something that makes a lot of sense and it also coincides with what DevOps is all about, right? So I think that’s a great addition.

    Shimel: Absolutely. Mark, let’s hear from you. You know, what’s Perforce’s take on this? Are you in violent agreement or maybe something else to it?

    Ties: I’m in violent agreement with the number of the comments that you’ve made. You know, the space – you know, the research that we’ve done around the space for the last three-plus years now is that this space and environment is going to consolidate, and as a result of that consolidation, you know, those players that can put together best-of-breed technology, that can bring the value that the customer’s ultimately desire or need will be – you know, they will be the players that will rise to the top, and we believe we’re doing that with our version control solution _____ Perforce with our _____ solution and now with web and mobile solutions with Perfecto along with the other technologies that we have. So I’m in violent agreement with that. You know, this won’t be the last acquisition that Perforce will do.

    I mean we’ve done five now; I could see us easily, you know, doing five additional acquisitions and continuing to grow this business. So that’s one point I’m in violent agreement with. The other point is that, you know, to your earlier point about the people and the culture and Eran’s as well, you know, it’s hard but it’s easy to buy a company. It’s harder to make that company successful –

    Shimel: Exactly.

    Ties: – during the acquisition, and I think all of the personalities on both sides of the fence with the Perfecto team and with our team are focused on one thing, which is creating a great company that has great products, phenomenal customer support, and then ultimately new customers. So it’s just – this is a great marriage and, you know, I look forward to continuing to drive it with my team with Eran and with Yoram and the entire Perfecto team.

    Shimel: Absolutely. On that point, let me ask what are the plans? Eran, will you be staying on? What will your role be? What about the rest of your executive team?

    Ties: Yeah so, you know, again, we’re in the days – we’re in the early days here, but the hope on my end is that Eran and team stay around and Eran will be leading this business as an independent segment, subsidiary, whatever you’d like to call it of the Perforce family reporting directly into me, so that is the plan. Now we do have teams obviously from both sides of the house working on the formal integration and how we’ll bring the companies together over the days, weeks, and months to come. We’ve just signed the agreement here earlier this week and we hope to close it by the end of the month.

    And, you know, we will take our time. We will be very diligent in what we’re doing here so that we do not disrupt either businesses, because right now both businesses have been very successful.

    Shimel: Excellent. Mark, I’ve got a question for you. You know, with each of the kind of deals and money raises that I mentioned earlier, I’ve spoken one-on-one with the CEOs, and one of the things I’ve asked them is what is their vision for how their company – you know, where does their company fit into the larger DevOps? You know, so for instance, GitLab wants the first true end-to-end DevOps product line. Shlomi Ben Haim at JFrog, they want a true DevOps platform that handles all artifacts, anything related to artifacts.

    Can you succinctly give us what is the vision – right? – for Perforce? What – you know, when you’ve done 5 more acquisitions, 10 more acquisitions, whatever it is, what’s the vision for what Perforce will become and what you’re striving for?

    Ties: Yes. So there are some very grandiose visions out there, and you’ve mentioned a couple of them. Ours is very simple; we want to be the enterprise player at scale. I mean we provide a very strong solution to enterprise customers that are looking for speed, scalability, security – to name a few of the attributes of the products that they’re purchasing and look to acquire as their providers. So that’s what we’re looking to do, win every inch. All right? We’re not gonna win every market vertical, but the verticals that we choose to go down our plans are to do nothing but dominate them, and so that’s why we’re looking for industry leaders like the Perfecto solution, like the Perforce solution and the others that we’ve acquired, to make sure that we continue to demonstrate the need that our enterprise customers have.

    Shimel: Fantastic.

    Yaniv: And this – and if I may, investing in the vision that Mark articulated around the enterprise aligns extremely well with what we were thinking back in a narrow – if you will, in a narrow space, which is around the continuous testing. But in the notion of addressing the enterprise and the specific ____ that we would be strong at, would make the vision, the joint vision, something that is really great, and that made it also very, very easy for us to _____.

    Shimel: Excellent, excellent. Well, gentlemen, let me wish you both success and congratulations. We’re about out of time here on this DevOps Chat, and I’m sure you’re both very busy. It is an exciting day. Maybe we can check back in a few months when the dust settles a little bit and see how things are going and where you’re headed from there, all right?

    Ties: Great. More than happy to –

    Yaniv: I’d be happy to.

    Ties: – continue the conversation. Thank you.

    Shimel: Okay. Mike Ties, CEO of Perforce, Eran Yaniv, CEO of Perfecto, Announcing the merger of their two companies, and as Perforce continues to scale in the DevOps space. Thanks for being this episode’s guest on DevOps chat, gentlemen. This is Alan Shimel for devopsy.kinsta.cloud and you’ve just listened to another DevOps Chat.

    — Alan Shimel