Category Archives: CLM

Application Security, Not so Black & White


May 8, 2013 By Ryan Berg

I’m glad to see that Simon Phipps, independent open source consultant and a director of the Open Source Initiative, promote the need to manage components effectively. In his recent InfoWorld article he notes:

“Cyber security is on the national political agenda, but do we really understand what it takes to be secure? Now that enterprise development has become component based, rather than using custom code running off-the-shelf platforms, it’s time for enterprise development to wake up and smell the black hats. They’re targeting your components, not just your servers.” 

Simon references our recent survey of 3500 developers, managers and architects that use open source software and our findings about the prevalence of OSS components. Things like:

  • Applications are made up of at least 80% components
  • Vast majority of organizations have not control over the components they use
  • Developers don’t focus much on security

His quote sums up the fact that applications are the predominant threat vector, and with the recent data that today’s applications primarily consist of components it should be no surprise that components can be a significant threat. Why? Well it comes down to economy of scale. If the hacker can exploit a single component, and that component is used in hundreds or thousands of independent applications, hmmm check and mate.

In another article on InfoWorld, Simon addresses Oracle’s approach to Java stating “Oracle’s closed approach keeps Java at risk”. I’m drawn to his comments comparing whether proprietary or open source software (in this case Java) poses a greater risk. This type of editorial has been going on for years – debating the merits of the “many eyes” theory. He also discusses how technical debt in proprietary systems is a more significant issue than can be found in open source. While I understand (though I don’t agree with his thoughts), I think there is a bigger problem here. Since applications are constructed from components sourced from many locations, organizations need to treat software security using supply chain principles. Components of all types need to be managed: internally developed components, open source components, shrink-wrap (COTS), cloud services, you name it.

The issues that are coming to light with Java may vary in technical detail, but their impact is similar to the pervasiveness of Windows ActiveX controls, Adobe PDF files, or other technologies. For those of you old enough to remember, think about the rampant issues found in UNIX’s open source Sendmail program. The point being, this is not an open source vs. closed source debate, this is an application security problem that is rampant across all communities.

Personally I am glad that Oracle is starting to step up to the plate and address these issues head on, but let’s not fault the fact that not all Java is open source. And let’s not lead people to believe that by making a project open source, that security is automatically improved. While there are lots of security stars in the open source community, there are plenty of black holes. As a security community, we need to promote better security practices across all development efforts and avoid generalizations that marginalize any one approach.

“Personally, I have always been a fan of bribery”


May 6, 2013 By Mark Troester

Here is another post on my favorite quotes from the Security at the Speed of Development webinar with Wendy Nather, Research Director, Security for 451 Research and Ryan Berg, Sonatype CSO.

When asked about how the security team can effectively collaborate with the development organization, Wendy (with tongue in cheek) responded:

  • Personally I have always been a fan of bribery. Buying food, lots of drinks.”

Wendy went on to provide the following advice:

  • “Helping the developers achieve their goals, not your goals, is what is going to lead you to working better together. If they feel that you are on their side, that they see you as assistance not as an obstacle. You really need to spend time with them, learn about what they are trying to do, see if there is any way you can help even if it has nothing to do with security.”

We took this approach and extended it in the design of the Sonatype CLM. We realize that if the security, licensing, development, and IT Ops teams are not on the same page, that application risk will not be managed effectively. We account for today’s modern development approach that uses short sprint cycles as part of an agile methodology.

  • The CLM provides guidance throughout the development lifecycle. The CLM prevents problems by providing information early in the lifecycle vs. a phonebook of potential issues that the developer has to address just before production.
  • Policies can be implemented that provide flexibility to the developer early in the development lifecycle while locking down production deployment. The CLM doesn’t force the developer through a laborious approval process before they can use a component.
  • The CLM allows the security team to assess overall enterprise risk and policy compliance. This information makes it easy for the security team to communicate with development management and executives. 

To see how policies can actually speed development & improve collaboration, check out the “Implement flexible policies that speed agile development with guidance for each lifecycle stage” section of the product tour.

Make sure you read Wendy’s research Mission Impossible: securing the open source software supply chain with Sonatype.

 

 

“They wait until the software flaw trends on Twitter”


May 3, 2013 By Mark Troester

Here is another post on my favorite quotes from the Security at the Speed of Development webinar with Wendy Nather, Research Director, Security for 451 Research and Ryan Berg, Sonatype CSO. Wendy was talking about how inertia makes it difficult to justify fixing security flaws later in the development lifecycle:

  • “Management will want to wait until there is an actual breech before they bring resources back to fix it.”
  • “That big corporation (with the 3 or 4 letter acronym) will wait until their software flaw is trending on Twitter before they are going to do something about it.”
  • On the resource commitment: “Fixes through change management… traceability for every fix that you make… getting the builds done… rebuilding it is going to be difficult… testing is going to take time… you may not have a slot in QA… and then there is deployment.”

Wendy also noted the need to protect the entire supply chain including assets that are sourced from third parties. Her Twitter reference implied that some suppliers will not address security flaws until negative publicity forces them to act.

Continue reading

“Good luck getting Mike to fix big security flaws.”


May 1, 2013 By Mark Troester

I’m writing several posts using my favorite quotes from the recent Security at the Speed of Development webinar with Wendy Nather, Research Director, Security for 451 Research and Ryan Berg, Sonatype CSO.

In this first post, Wendy was talking about the need to integrate security in from the beginning…

  • “The best place to set security standards is across the board before any projects get started. If you have the same requirements for everyone right out of the gate you’ll have less to change for each individual project.”
  • “In QA, it’s almost too late, all the time and resources that were budgeted for the project will have been used up. It’s extremely hard to sell the concept of going back and changing the design. The inertia here to get management to slow the release or to fix problems is really big.”
  • “In production you have the greatest inertia. It has already been rolled out, it’s running just fine and the developers have been reallocated to other projects. There is one poor guy named Mike left to support it along with 2 or 3 other applications. Good luck getting Mike to fix big security flaws.

The interesting thing about Wendy’s recommendation is that it represents a key design principle of the Sonatype CLM. Integrating security throughout the entire lifecycle – from design, development, on through production deployment.

With the CLM, it starts by providing security, licensing and quality information in the IDE so the developer can make informed decisions about the best components to use. This prevents problems from occurring downstream, problems that become more expensive to fix.

To learn more about Sonatype CLM, check out the product tour.

Make sure you read Wendy’s research Mission Impossible: securing the open source software supply chain with Sonatype.

 

 

CLM Customer Impressions


April 30, 2013 By Mark Troester

We thought it would be interesting to share some of the feedback that we are getting from early CLM customers.

Check out the CLM product tour to see more and come back to the blog to post your impressions.

Policy & governance

  • “Just by using the CLM we are enforcing policy.” – Dev Manager
  • “A week is too long to wait for approval. The CLM automates the process and provides visibility.” – Agile developer
  • “For products to effectively govern, they must have high usability. With CLM, it’s really easy to build and reuse policies – there are no special tools that are required, just a Web browser.” – Lead Architect
  • “Integrating disparate data (from other security tools) while automating policy is transformative for our processes.” - CISO

Simplicity

  • “If you can’t make it simple, you can’t make it secure.” – Enterprise Architect
  • “We need a zero overhead approach that doesn’t require weeks of user training. That’s what we have experienced with other alternatives – but your approach is different.” – Dev Manager
  • “The CLM reduces the impedance for developers that results in non-compliance. Your policy enforcement approach eliminates the biggest reason for developers not to comply with FOSS policies – you eliminate delays caused by manual component reviews.” – Security Analyst
  • “If you can’t make governance simple, you’re creating more barriers to making it secure.” – CISO
  • “We didn’t have to learn new tools, information we need to take action is in the tools we use.” - CTO

Nexus users

  • “We have been using Nexus for years and the Nexus Pro features are interesting. Since we are really focused on security, the CLM is what we need.” – Dev Manager
  • “Don’t build the tool to be tool agnostic… Maven is all you need!” – Maven Fanatic <Editorial note: the CLM is tool agnostic, it is designed to support multiple IDEs, Repo Managers, Build & CI tools>

OSS management 

  • “You are the only company that combines component binary repository with FOSS governance: a single view and repository (approvals + component metadata + binaries + promotion model).” – Open Source Board Manager

Remediation support

  • “With the CLM, I can quickly replace flawed components in my application without leaving the IDE.” – Lead developer

Securing your apps

  • “You help support our “defense in depth” strategy – CLM provides centralized FOSS rule management with multiple enforcement points (IDE, CI server, binary repo, deployment promotion etc)” – CISO
  • “For products to effectively govern, they must have high usability. With CLM, it’s really easy to build and reuse policies – there are no special tools that are required, just a Web browser.” – Security Admin

CLM complements security scanners

  • “When we presented CLM to the security team Fortify… they were very excited… they liked it because they can focus their efforts on code built in house.” – Application Architect
  • “Sonatype provides the ability to identify issues early in the process, that decreases our development cost. Using Sonatype will allow the Fortify team to focus on things that are more likely to have issues.” – Dev Manager

CLM: It’s better than the competition!

  • “When you have as many apps as we do and you can’t scan them automatically… and you don’t have a degree in rubbish… vendors that require long scan times that produce a lot of results don’t work for an organization of our size.” – Architect Manager
  • “With vendors that have long scan times… you can’t have those lead times, we need to be able to know whether a component is suitable to use right away. There is also no way to tie it into our system, it was simply opt in… people have to submit things and it takes several days to get it approved. We can’t wait for this, we are under pressure to deliver… we are going to forge ahead, we are going to ask for forgiveness.” – Lead Developer