Category Archives: Sonatype

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.

“I want to write really insecure code today”


May 7, 2013 By Mark Troester

This is the last in my series of blog posts 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 how organizations can hire good security talent in today’s competitive marketplace, Wendy noted:

  • “Some of the best app security people that I have seen are really good developers that picked up the security mindset and learned more about it. If you have really smart architecture people… developers that already know your applications, and they have the right mindset to learn the hacking side of things, they can make really good app sec people.”

Ryan went on to explain:

  • “Developers are the front line – but you really need to have both. Since developers understand the development process they make good security people… Having someone that is part of the agile development process, who understands the business requirements. You need the security angle but you need to think about usability and how things might be exploited. Developers can bring a balanced view because they understand how the development organization works.”

And Ryan commented on how management has to be committed to security:

  • “I haven’t found a developer that says ‘I want to write really insecure code today’… half the time they don’t have the tools, the training, or the backing of the organization that says security is an important thing and this should be something that is part of your day-to-day responsibility.”

Continue reading

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