devopsy.kinsta.cloud

Tag: Veracode

  • DevSecOps: Security Needn’t be Sacrificed for Speed

    DevSecOps: Security Needn’t be Sacrificed for Speed

    With the right practices, security needn’t be an impediment to continuous development and rapid improvement.

    The same cycle keeps repeating, according to IT security and risk management consultancy Sense of Security co-founder and CTO Murray Goldschmidt. A new technology is hyped, leading to rapid adoption, but security is left as an afterthought. It happened with WiFi and voice over IP (VoIP), he says, and is currently happening with the internet of things (IoT). But it doesn’t have to be that way.

    DevSecOps: DevOps + Security

    DevOps is good for making things better, faster. But there tends to be a culture clash between those talking about speed, velocity or agility and those concerned with issues such as control points.

    So Goldschmidt and his colleagues are showing their clients how security can be integrated into DevOps (DevSecOps) in an automated manner without affecting velocity.

    Most people with development, operations or cloud backgrounds aren’t well-versed in security, he suggests, so Sense of Security shows clients how DevSecOps means security and DevOps can run in parallel.

    “It’s not that complicated,” he says, but it’s something most people don’t think about.

    Organizations often have a vulnerability management life cycle to identify and treat issues. After all, that’s part of various industry standards.

    The typical approach is an annual penetration test to find issues, which can then be addressed.

    A better way is to move to automated testing, and there are various commercial and open-source products to do that job. Goldschmidt says he sees little resistance to this idea.

    The next step is to go from scheduling these vulnerability scans on a quarterly basis to weekly or daily—or even to run them continuously.

    Citing the Struts vulnerability that caused a big problem for Equifax, he notes the challenge is to identify vulnerabilities in your systems before an attacker does. Continuous automated scanning means the window of vulnerability is very narrow.

    This idea is simple enough, he says, but for some reason it doesn’t occur to most people until someone brings it to their attention.

    When a scan reveals a vulnerability, its significance (severe, medium, etc.) is used to prioritize remediation.

    “DevOps guys understand those triggers,” he observes: If you give them the data, they can take the necessary actions. For example, that might mean shutting down the servers in a small web farm one at a time, applying the patch, restarting and moving on to the next. They could all be patched and running by the end of the day.

    Patching Isn’t Everything

    However, “it is unfair to assume organizations can patch things quickly” every time, he says. For example, the Struts vulnerability required more than just a patch—the code running on it had to be recompiled and tested, and that process could take months in a large organization.

    So organizations should not rely on the idea that patching is the fix for a vulnerability. While patches will be applied eventually, if you can make it difficult to actually take advantage of any exploits, the risk of data breaches is very low.

    One very easy-to-implement example of these measures is using a stateful firewall to ensure inbound-only access to web servers. By disallowing outbound access—”the channel through which data is lost”—there is no path for data to leave.

    Goldschmidt also recommends using tools to examine in-house code and the open-source and commercial code that is used with it. Such tools can detect most common problems, including openings for SQL injection, cross-site scripting and token misuse.

    He describes these tools as being the equivalent of “spellcheck for developers,” and says it reduces the likelihood of putting insecure code into production.

    The market includes products from Veracode (now part of CA), Sonatype and Qualys.

    Qualys, he notes, provides differential reporting. This makes it obvious that something has changed, and “that is the key to automation.” Whether the system itself has changed or new information has been discovered about vulnerabilities or configuration issues, action is required.

    Furthermore, the ease of making configuration changes that could have security implications makes continuous scanning even more important.

    These checks should not be limited to individual modules. Rather, they should be repeated—preferably automatically—as modules are assembled to help developers avoid poor code and to check the overall product.

    RASP Away Some Attacks

    Runtime application self-protection (RASP) is another technology Goldschmidt advocates. The idea is to detect abnormal and possibly malicious activity. One example is that normal operation would see an application communicating with its application server, and the application server communicating with the database. If the application suddenly makes a direct request to the database—as happens in an SQL injection attack—action is clearly required.

    Depending on the situation, RASP might raise an alert or immediately terminate the application, among other possibilities.

    The use of these and other technologies and techniques should allow organizations to run at the pace implied by DevOps without sacrificing security.

    — Stephen Withers

  • CA Technologies Positions Automic at the DevOps Core

    CA Technologies Positions Automic at the DevOps Core

    After acquiring Automic earlier this year, CA Technologies suddenly found itself with an embarrassment of IT automation riches. Now the company is moving forward by further integrating the Automic IT automation platform with the rest of the portfolio of tools and services that it says are required to construct a software factory.

    Ron Gidron, technology evangelist for Automic, says the latest version of Automic increases the number of integrations with the rest of the CA Technologies portfolio to include support for CA Test Data Management, Service Virtualization, Privileged Access Governance, Application Performance Management and Veracode application security software, among others.

    CA Technologies has made it clear it intends to make the release automation software originally developed by Automic the foundation of its overall DevOps strategy. Most of that effort is now focused on integrating the various elements of the CA Technologies portfolio. Longer term, CA Technologies will eventually move to rationalize any duplication in functionality.

    Version 12.1 of Automic also brings forward orchestration tools and self-service capabilities to enable developers to provision resources within guidelines defined by IT. Gidron says that while there will always be a need for IT operations specialists, CA Technologies is making a concerted effort to “shift left” to provide developers with more programmatic control over the IT environment. To facilitate that process, Automic and the rest of CA Technologies have been investing in creating a standard set of external-facing REST APIs, which also will be used to make it easier for products and services created by the company to consume a wide variety of external data and metrics.

    Via acquisitions and internally developed software, CA Technologies is clearly trying to unify application, infrastructure and security management with the context of a single DevOps framework. The company doesn’t plan to force organization to consume that entire stack of software. But it will try to make acquiring as much of its portfolio as financially attractive and frictionless as possible to drive what the company describes as intelligent automation across a modern software factory. Driving that need is the realization that just about every company in every industry is now dependent on some form of custom software to drive one digital process or another.

    The rate at which CA Technologies has been expanding its DevOps portfolio via acquisition is a major contributor to what appears to be a wave of consolidation starting to occur across the DevOps category. Regardless of how advanced any organization might become in terms of building a software factory, major IT vendors realize that it’s only a matter of time before IT organizations start to pressure them to bundle more DevOps-related functionality together. In fact, the line between what’s DevOps today and tomorrow versus what was considered traditional IT management appears to be getting more blurred with each passing day.

    — Mike Vizard

  • DevOps Chat: Developers and Security with Pete Chestna, Veracode

    DevOps Chat: Developers and Security with Pete Chestna, Veracode

    In this DevOps Chat we speak with Pete Chestna of Veracode about the roles and opinions of both developers and security pros about how and who should be working on security in the enterprise. Much of the discussion centers on a survey Veracode conducted with consulting firm Enterprise Strategy Group (ESG).

    Pete is always a great interview with a common-sense approach to DevSecOps borne from being both a developer and security pro. I am sure you will enjoy this discussion. As usual, the streaming audio of our discussion is immediately below and the transcript of our discussion is below that.

    Audio

     

    Transcript

    Alan Shimel: Hey, everyone, this is Alan Shimel of devopsy.kinsta.cloud here for another DevOps Chat. Today’s guest on the chat is Pete Chestna, Veracode, a CA company, director of developer engagement. And that’s a fancy way of saying Pete’s out there talking to developers about bringing security, shifting it left, bringing it into the developer universe and making all of our apps more secure. Pete, welcome to DevOps Chat.

    Pete Chestna: Thanks, Alan. Pleasure to be here.

    Shimel: Yep. So, Pete, you and I have, of course, crossed paths before and I’ve seen you present and you’re a knowledgeable, knowledgeable person, in terms of how security is continually kind of making inroads into the developer community and kinda convincing them that security’s everyone’s responsibility, right? That security isn’t just the purview of the security team; it’s everyone’s job. And you’re doing a heck of a job with it, which has, I think, attested to Veracode’s value in the market and its place in the market, so great job there.

    Chestna: Thanks.

    Here are some other DevOps Chats you may want to listen to:

    Node.js Becoming More DevOps-Friendly
    DevOps Chat: State of DevOps Report 2017, Nigel Kersten, Puppet
    DevOps Chat: Why Real Transformation Starts with Culture, Bryson Koehler and Shelbee Smith-Eigenbrode, IBM

    Shimel: Pete, what we’re gonna talk a little bit about today is that Veracode recently conducted a survey of developers and security folks, talking about this very subject. And I wanted to share it with our audience a little bit, if you can. Why don’t we start with what you consider sort of the headline of this survey?

    Chestna: Thanks. So this was done with the enterprise strategy group and the key takeaway for this is, really, again, it’s reinforcing the messages we already bring out to the market, so we need increased accountability. The reason that developers don’t take security more seriously is because they’re held to account for their functionality and not necessarily their security, so, if we bring in metrics and goals into the equation, for developers, we’re gonna see an increased uptick in the way they think about security. It’s about building relationships with your security team, so security and developers need to work together to build that relationship, so, that way, they feel like there are people on each side and not just a function.

    And, really, it’s what I call the “three-legged barstool of application security.” It’s about training, making sure developers are trained—a lot of the times that they don’t wanna develop these tools is because they don’t know what to do with the results. Second is integrate and automate—if you bring it into their toolchain and make it easy for them to use, then they’re more likely to use it. And, lastly, it’s about helping them fix what they find—again, this knowledge gap of, “What is across-site scripting? What is OS command injection?” Help them understand how to fix these and prevent them makes them more likely to adopt these tools and make security a better part of their work.

    Shimel: Got it. And you know what, Pete? So I’m up here in Boston, recording this, and we just finished a DevOps Connect. I had an interesting question from the audience yesterday, and a gentleman said, “Well, our developers kinda get paid or judged on how much code they commit. And to go back and tell them that the code they committed, you know, it had vulnerabilities and they gotta fix it, it really upsets them.” I’m sorry for them, right, Pete? But –

    Chestna: Right.

    Shimel: – to me, it’s kind of—you know, I used to see this problem with running sales teams and stuff like that. You’ve mismatched incentives here. Right?

    Chestna: Oh, absolutely.

    Shimel: You know, and that has to be—and that’s not the developer’s or the security guy’s fault; that’s management’s fault.

    Chestna: Yeah, if we don’t take accountability for what we’re doing, if we don’t hold the developers—so, you know, I always look at the security team. They are responsible for security but the developers need to feel accountable for security. And you’re right; it’s management that needs to say, “We’re gonna measure you on this and it’s gonna be part of how we evaluate you at the end of the year.” That will drive the right behaviors. They’re gonna do what they get paid to do. And if they get paid to produce functionality faster, that’s exactly what they end up doing.

    Shimel: Yep. And so this is apparently something, I think, we need to solve. You know, we’re gonna see real progress in the area. But, look, let’s save that for another day. Pete, can you share some more of the findings on the survey with us?

    Chestna: Yeah, absolutely. So a couple of things that stood out to me, as I read through it, was there’s a increased maturity as far as adoption of Agile and DevOps. There’s only 5 percent of respondents that said they have no Agile in their shop at all, where 18 percent say that most or all of their products are using a Agile methodology. And then it goes on from there—28 percent is more than half. So we’re seeing a really good adoption, at least of Agile. And then if you think of DevOps usually being run on an Agile methodology, only 6 percent of respondents says they haven’t adopted DevOps at all and 17 percent are reporting that they have extensively adopted it, so great numbers, as far as people coming up to speed in doing this. And, as far as making things easier, 45 percent of respondents said that DevOps makes it easier for them to developer software, including security, which is a great finding.

    Shimel: That is—what was the number? 45? Just about half?

    Chestna: Yeah.

    Shimel: Excellent.

    Chestna: So those must be shops that are doing it well because they’re seeing the benefits that you get from experiencing DevOps.

    Shimel: Well, I mean, you know, Pete, you take this, I think, in conjunction with the recent release—I was out in London last week for DOES and the folks at DORA and Puppet released the State of DevOps for this year’s survey and results, and it dovetails nicely here, where DevOps-enabled organizations deal with something—I forget what the number was—15 percent less vulnerabilities or 15 –

    Chestna: Right.

    Shimel: It was some –

    Chestna: It was from the Puppet report.

    Shimel: – eye-popping number of the improvement in the quality of code, vis á vis security. So it seems to make sense, but you know what, Pete? I’m amazed that something that seems so, you know, simple, so elementary, if you will, is still—we’re still talking about only half of organizations, a little less than half organizations doing it. What do you think is holding back the other half?

    Chestna: It’s the culture. You know, people wanna maintain their silos. I see it all the time where the management—again, we’re going back to management, as a problem here—they wanna hold on to their silos and their power. And if you look at where DevOps takes a company typically, if you do it whole-hog and embrace everything, you’re reorganizing, so someone that has a large quality staff reporting to them is now gonna have that broken up and disseminated into other teams, and now they’re gonna be responsible for other functions or they’re gonna have to go find another job. So there’s this big unknown and fear for them of, “What does the future hold if I just don’t do quality and I have to actually produce product?” So this cross-accountability is just—is scaring the hell out of them.

    Shimel: Yeah. Yeah. But you know what? Let’s not put it all on the dev side of things; let’s talk a little bit about the security folks, too. And, Pete, you and I both come from the security world. There are a lot of security people who get very territorial, you know, to say the least, around running scans, being the ultimate deciders of what’s secure and not secure, and they’re just as resistant to change, from a cultural point of view, as dev teams are sometimes. I mean, do you agree or –

    Chestna: Yeah, and they white-knuckle the release, so –

    Shimel: Yeah. [Laughs]

    Chestna: – I’ve talked to a lot of people that say, “Hey, it’s gotta be pen-tested. I have to pen-test everything.” If you’re talking about releasing multiple times a day, there’s no way in heck that you’re gonna be able to do that. So you have to pick your battles and say, “This is important. It touches crypto or this touches authentication or authorization. It has to be pen-tested,” versus, “I can use the easy, least expensive way of SAST and DAST to go and find vulnerabilities and I can trust that those tools will find things.” So it’s that back-and-forth of how much security needs to be in there and how assured do they need to feel before they can sleep at night.

    Shimel: Mm-hmm. And they’re ultimately, Pete—you know, I think, when we look at surveys like this and we talk about the view of the security team versus the view of the dev team, view of management, really, the way to kinda bridge these gaps and bring this all together is really a lot of the kinds of things that you do. Right? You’re out there, talking to the different constituencies around the world, almost constantly—we were talking off-mic about how much both of us have been traveling—but there’s a mission there to bring these tribes together, if you will, and forge a common path and a common way of working together. And I think, if we take surveys like this and we look at the results and we share those results with the two teams, again, it becomes sort of like, “Duh. What are we fighting about?”

    Chestna: Oh, exactly. So, I mean, if I go back to the survey for a second here and look at how people are being measured, 33 percent of respondents say, “I’m being measured on functionality that I released,” versus only 18 percent that are saying, “I’m being judged on security.” So, if you look at that number and say, “Well, what are they doing? Their actions reflect how they’re being measured, so let’s change how they’re being measured and see if that changes what they think about their jobs.” The people that responded and looked at “Does DevOps help me with security, the ability to automate and integrate?” 58 percent of respondents said, “Hey, it allows me to do this integration and automation,” which is one step toward getting them to actually pay attention to those results.

    Shimel: Yeah. And 58 percent is a sizable majority.

    Chestna: Yes.

    Shimel: That is Pete, I don’t know if you have the insight on this, but these were large enterprises, primarily, that were surveyed here?

    Chestna: Yes, most of them were—98 percent were 1,000 or more employees.

    Shimel: Okay. Now were there any particular verticals that were highlighted or anything?

    Chestna: The biggest ones were IT at 23 percent and the finance industry at 21 percent.

    Shimel: Oh, okay, there you go. And those are both pretty DevOps-savvy, if you will, or maybe early—no, I don’t wanna use the term “early adopters,” ’cause finance is very rarely an early adopter, but, I mean, certainly, DevOps has taken a strong foothold within the financial and financial services industry, so.

    Chestna: Yeah, and the thing is driving them is really the regulatory compliance, so 53 percent of respondents said that, “We’re doing app-sec because of regulatory.” Forty percent are saying it’s because of corporate governance. And an interesting stat here was 34 percent said it was because of customers or partners, so the great news is people are starting to pay attention to their software supply chain, to say, “Am I getting secure software to install in my environment?” and they’re asking customers to prove that they are. And, hopefully, that also means that outside customers, like individuals, are also looking at security as an important decision in where they go and where they spend their money.

    Shimel: Yep. I agree. I mean, it is interesting stuff, Pete. So, Pete, where do we go from here with this now?

    Chestna: So I think the next step is to continue the journey that you and I are on, of helping security understand development, help development understand security, tell them that they need to build in accountability. It’s built by relationships, so they have to work together. If security starts to teach developers how to do secure development and explains to them how to fix the things that they’re finding, developers are more likely to engage because it’s not this great unknown of “Hey, I don’t wanna go in and fail. I don’t wanna go in and look like an idiot,” or, “I don’t wanna go in and not understand what I’m doing.”

    So security needs to take their part and companies need to understand that training and development and education around security is a carrying cost of having developers. They were never trained to do it and they have to pick that cost up; it’s not like they can just throw them all away and bring in new developers because the developers that they bring in are gonna have the same problem. So getting that education done leads to better engagement, leads to better results.

    Shimel: Agreed. And you know what, Pete? Just a shameless plug on that note: I’m gonna be out in Singapore at the end of July, at the RSA APJ show, putting on another DevSecOps event at RSA, and we’re working with both the local—so it’s interesting. In Singapore, there’s almost a 900-person-strong DevSecOps MeetUp group, which is huge for that area of the world, and there’s an equally-as-big DevOps MeetUp group. And we’re working with both of these MeetUp groups, as part of this event, and we’re really—I’m hoping to really kinda bring these tribes together and make it happen. Of course, I’d –

    Chestna: Sounds great.

    Shimel: – you to come out. You’re in Black Hat at that time.

    Chestna: Yes.

    Shimel: Are you speaking at Black Hat, Peter?

    Chestna: I’m not. I’m doing customer stuff, customer-facing.

    Shimel: Ah, very good. So you’ll be in hot Vegas and I hear Singapore’s pretty warm now that time of year as well. Well, we continue along our mission of spreading the good word, right?

    Chestna: Yes, sir.

    Shimel: as they say. Anyway, so, Pete, we’re about out of time. I know you don’t have the URLs off the top of your head right now, but we will include them in the show notes for people to download the results of the survey and the report, maybe find out a little bit more, but I wanted to thank you for sharing and giving us a little bit of insight into the results. And then keep up the great work, Pete. You do good stuff.

    Chestna: Thanks. I appreciate your time, Alan.

    Shimel: All right, Peter. This is Alan Shimel for devopsy.kinsta.cloud’s DevOps Chat and we’ll see you on the next chat.

    — Alan Shimel

  • Veracode Makes DevSecOps Transition Easier for Developers

    Veracode Makes DevSecOps Transition Easier for Developers

    Following the formal acquisition of Veracode by CA Technologies, a much bigger effort to make security a more integrated element of DevOps has kicked off in earnest.

    Veracode recently unfurled an update to its application security platform aimed specifically at developers that provides security findings as each application module is scanned. Tim Jarrett, senior director of enterprise security strategy for Veracode, says the idea is to provide developers with that information from static analysis delivered via the Veracode platform as early in the application development lifecycle process as possible.

    Other new capabilities include support for custom cleansing functions to automate remediating issues involving common known vulnerabilities and an auto-scan capability that gets implemented any time a file is saved.

    Also with this release, Veracode is adding support for the Perl programming language that is still widely used for building web applications.

    Jarrett notes that organizations these days are holding developers more accountable for security issues that are easier to fix during the application development process. Addressing those same issues after an application is deployed in production not only exposes organizations to security threats, but can be much more expensive to fix.

    The challenge is that most organizations have yet to solve the riddle for getting developers to address security issues earlier in the application development cycle. Jarrett says far too many developers are conditioned to view IT security has being someone else’s job inside the organization. Veracode is trying to make it simple to address security issues using tools that make the process as frictionless as, say, relying on a spell checker to publish a higher-quality document.

    Obviously, there will never be perfect security. But far too many of the issues that IT security teams regularly deal with relate to known exploits. At a time when cybercriminals are making use of a variety of automated tools to discover those exploits, most IT security teams are outgunned. Worse yet, many IT organizations can’t even find qualified cybersecurity professionals to hire in the first place.

    On the plus side, however, as DevOps processes mature, many developers are now assuming complete responsibility for the maintenance of the code they write, including all security issues. This not only leads to higher-quality applications, it also results in those developers being more vigilant when it comes to address security issues they would otherwise need to address themselves once an application is deployed in production. In some quarters, this earlier focus on security in the application development and deployment process is referred to as DevSecOps. As a discipline within most IT organizations, however, DevSecOps remains relatively nascent.

    Of course, regulatory bodies are increasingly treating organizations that fall prey to security attacks less like victims. Instead, they are holding them accountable for ignoring best security practices by assessing fines for losing control over sensitive data. As those fines increase the blame for incurring those fines eventually cascades back to the developer. Given that changing climate, it might not be too long before developers recognize that embracing DevSecOps is in their own best interests.

    — Mike Vizard

  • CA Technologies Completes Acquisition of Veracode

    NEW YORK–(BUSINESS WIRE)– CA Technologies (NASDAQ:CA) today announced it has completed the acquisition of Veracode, a leader in securing web, mobile and third-party applications across the software development lifecycle. The acquisition establishes CA Technologies as a leader in the Secure DevOps market, bridges its Security business with its broad DevOps portfolio and adds to its growing SaaS business.

    With the completion of the transaction, Bob Brennan, former chief executive officer, is now general manager of the Veracode business in the company’s product development organization reporting to Ayman Sayed, CA president and chief product officer.

    Under the terms of the agreement, the transaction is valued at approximately $614 million in cash.

    CA will provide detail regarding the acquisition’s impact to guidance when it reports fourth quarter earnings in May.

    About CA Technologies

    CA Technologies (NASDAQ:CA) creates software that fuels transformation for companies and enables them to seize the opportunities of the application economy. Software is at the heart of every business in every industry. From planning, to development, to management and security, CA is working with companies worldwide to change the way we live, transact, and communicate – across mobile, private and public cloud, distributed and mainframe environments. Learn more at www.ca.com.

    — Jules Louis

  • CA Technologies to Acquire Veracode, a Leading SaaS-based Secure DevOps Platform Provider

    NEW YORK, March 6, 2017 – CA Technologies (NASDAQ:CA) today announced it has signed a definitive agreement to acquire Veracode, a leader in securing web, mobile and third-party applications across the software development lifecycle, for approximately $614 million in cash. The transaction is expected to close in the first quarter of fiscal year 2018, and is subject to customary closing conditions, including regulatory approvals.

    The combination of CA’s portfolio with privately-held Veracode will establish CA Technologies as a leader in the Secure DevOps market through the automation and scaling of application security testing (AST) to develop and deploy applications faster with fewer defects. With Veracode, CA Technologies bridges its Security business with its broad DevOps portfolio and adds to its growing SaaS business. Veracode extends CA’s go-to-market strategy into midsize enterprise customers while CA accelerates Veracode‘s global reach into larger enterprise customers.

    “Security testing is growing faster than any other security market, as AST solutions adapt to new development methodologies and increased application complexity. Security and risk management leaders must integrate AST into their application security programs.”* Increased deployment of web and cloud-based business applications has further propelled the market growth. “By 2019, more than 50 percent of enterprise DevOps initiatives will have incorporated application security testing for custom code, up from less than 10% in 2016.”**

    “Software is at the heart of every company’s digital transformation. Therefore, it’s increasingly important for them to integrate security at the start of their development processes, so they can respond to market opportunities in a secure manner,” said Ayman Sayed, President and Chief Product Officer, CA Technologies. “This acquisition will unify CA’s Security and DevOps portfolios with a SaaS- based platform that seamlessly integrates security into the software development process. Looking holistically at our portfolio, now with Veracode and Automic, we have accelerated the growth profile of our broad set of solutions. We now expect that the size of our growing solutions within our Enterprise Solutions portfolio will eclipse the more mature part of the Enterprise Solutions portfolio in FY19.”

    The ability to deliver Identity and Access Management, DevOps tools and automation capabilities with SaaS-based application security, allows CA to offer enterprises of all sizes a faster time-to-value from their software investments.

    Digital transformation requires an integrated and agile approach to security. Code-vulnerability risk is mitigated and time spent identifying and fixing security issues in production is reduced when security testing is shifted earlier into the application development process. According to data from the National

    Institute of Standards and Technology, “it’s 30x more expensive to fix a vulnerability during post- production than during the design, requirement identification and architecture stage.”

    Named a leader in the Gartner Magic Quadrant for Application Security Testing***, Veracode’s solution enables automated, on-demand application security testing starting at the earliest phases of the development lifecycle to improve testing speed, address security concerns in production, and eliminate risk. In addition to dynamic application testing, the SaaS-based application security testing software and solutions also perform static testing to detect potential vulnerabilities in custom code, third party applications and open-source components.

    “We provide over 1400 small and large enterprise customers the security they need to confidently innovate with the web and mobile applications they build, buy and assemble, as well as the components they integrate into their environments,” said Bob Brennan, CEO, Veracode. “By joining forces with CA Technologies, we will continue to better address growing security concerns, and enable them to accelerate delivery of secure software applications that can create new business value.”

    Founded in 2006, Veracode has offices in Burlington, MA and London and has over 500 employees worldwide.

    Expected Financial Impact

    Assuming the transaction closes in early April, CA Technologies preliminary expectation is that the acquisition will:

    • Add two to three percentage points of revenue, both as reported and in constant currency. As a result, fiscal year 2018 total revenue is expected to increase in the range of 1 percent to 3 percent as reported, or 2 percent to 4 percent in constant currency. At December 31, 2016 exchange rates, this translates to reported revenue of $4.06 billion to $4.14 billion.
    • Impact GAAP and non-GAAP total company operating margins, such that fiscal year 2018 GAAP operating margins are expected to be in the range of 26 percent to 27 percent and non-GAAP operating margins are expected to be approximately 36 percent.
    • Have a modestly adverse impact on GAAP and non-GAAP diluted earnings per share, and cash flow from operations, both as reported and in constant currency in fiscal year 2018 and fiscal year 2019.
    • Be accretive to net income in fiscal year 2020.
      The combination of acquisition-related expenses and purchase accounting adjustments, in addition to the structurally lower margin profile of the SaaS business model, is expected to impact CA’s fiscal year 2018 and fiscal year 2019 results.

    — Jules Louis

  • Veracode Puts Developers in the Driver’s Seat When It Comes to Creating Secure Software

    Burlington MA—July 25, 2016—Veracode today announced Veracode Developer Sandbox, a patented new feature in the Veracode application security platform.  Developer Sandbox changes the dynamic between developers and security/risk teams, giving developers more control of the application security process early in the development lifecycle while improving the accuracy and effectiveness of formal policy-based software review processes.

    With Developer Sandbox, developers can scan full applications or individual components as they write them, so they can make improvements before sending the software for a formal policy or security review. This helps eliminate the ‘scan and scold’ dynamic that’s existed in the past, where even scans of early versions of code fed results to security and risk teams, creating the perception of software risk or compliance failures for the business well before the application is launched or the developer had a chance to make changes.

    Developer Sandbox also helps developers working in agile or DevOps environments, because it enables earlier, more frequent testing of code for security risks as software is being developed, fitting into shorter development cycles and more frequent release cadences. The result is higher-quality code entering the formal review process, reducing the chance that critical security risks are identified late in the development process which can force a no-win decision between delaying release or incurring business risk.

    “Developers have sometimes been left out of the security discussion in the past,” said Sam King, Chief Strategy Officer for Veracode. “The reality is developers want to write great code that’s secure code, but often don’t have access to tools that fit with the way they work. Developer Sandbox will help change that equation, giving them access to the industry’s most powerful application security platform in a way that works for them.”

    Software developers often don’t have formal training in secure coding practices. In fact Veracode’s State of Software Security report shows that security risks are sometimes introduced through misconfigured SSL or encryption – the very features initially implemented to improve security. Veracode Developer Sandbox uses the full Veracode static scanning engine, which has been tuned and improved through the experience of scanning nearly 2 trillion lines of code. This gives these developers who may not have deep security skills a powerful aid in creating more secure code, as well as a place to practice and learn to code securely.

    In conjunction with tools such as Veracode’s Software Composition Analysis, which identifies risks in the open source components often used in software development today, and Veracode’s in-line education tools that help developers learn how to fix vulnerabilities as they write their code, Veracode is making secure software development an easier, more seamless part of the entire software development lifecycle.

    About Veracode

    Veracode is a leader in helping organizations secure the software that powers their world, whether it is software they make, buy or sell. Veracode’s SaaS platform and integrated solutions for application security provide an end-to-end approach from code creation to application deployment. The Veracode platform incorporates technology, expertise and workflows into a unified, efficient solution for developers and security teams as well as enterprise risk and compliance functions.

    Veracode serves over a thousand customers across a wide range of industries, including nearly one-third of the Fortune 100, three of the top four U.S. commercial banks and more than 20 of Forbes’ 100 Most Valuable Brands.  Learn more at www.veracode.com, on the Veracode blog and on Twitter.

    Veracode is a registered trademark of Veracode, Inc.  All other brand names, product names, or trademarks belong to their respective holders.