Author: Pete Chestna

  • Securing Third-Party and Open Source Code Components: A Primer

    Securing Third-Party and Open Source Code Components: A Primer

    The increasing popularity of open source code continues to be a boon for developers across the industry, allowing them to increase efficiency and streamline delivery. But there are security risks to be considered when leveraging open source and commercial code components, as each carries with it a significant risk of becoming the enemy within, creating a vulnerability in the program it helps build.

    Sacrificing Security for Ease of Use

    While the many benefits of open source have been well-touted, the sheer prevalence of code components (open source and commercial) across industries is underestimated. CA Veracode recently found that 83 percent of developers use code components to build web applications, with the average number of components per application at a whopping 73.

    Considering the fact that the vast majority of developers build applications with code components, the number of those familiar with the risks of doing so is startlingly low. A mere 52 percent of companies reported they provide security fixes to components when new security vulnerabilities are discovered. Despite an average of 71 vulnerabilities per application introduced through the use of third-party components, only 23 percent reported testing for vulnerabilities in components at every release.

    Furthermore, only 43 percent of developers reported being aware of the industry-accepted OWASP recommendations for preventing the use of components with known vulnerabilities.

    Where Does Responsibility Lie?

    One clear issue in this software development practice is that responsibility for securing code seems to fall on everyone—and, sometimes, no one. Forty-four percent of respondents claimed that developers are responsible for the continued security of code components, while 31 percent reported that they expect security to handle this task.

    This lack of preparedness and miscommunication leaves the door wide open for bad actors to swoop in and take advantage of vulnerabilities that could so easily be fixed.

    How, then, can teams ensure the security of applications built with code components? The solution lies in three key steps:

    • Start with education: Software development teams must have the tools and training necessary to ensure the code they write is secure. Educating developers on the risks associated with open source and commercial code components is a start, but prioritizing security training and ongoing education is the key to long-term success. Tapping the security team to lead trainings for their developer colleagues is a good way to embrace peer knowledge-sharing and break down silos between the two teams.
    • Introduce clear processes: To alleviate miscommunication and confusion, organizations must implement clear processes for secure software development. Knowing what an application is built of is the first step, as teams can’t secure what they don’t understand. This may seem obvious, but CA Veracode found that only half (53 percent) of organizations keep an inventory of components. Code components should be thoroughly vetted before being worked into an application and then should be added to a working inventory. Managers should be sure each part of the maintenance process has a clear owner on the team so responsibility is always clear. Consistent testing and patching are also best practices when it comes to security.
    • Drive innovation with DevSecOps: All of this comes back to integrating security into the entire software development life cycle (SDLC) and implementing DevSecOps, because a team that operates in silos will never be able to push out secure code. The development, operations and security teams each provide their own unique and critical contribution to the software development process, and combining forces will result in the best possible product.

    While taking the time to secure applications from the perils of code components may slow down development in the short term, safeguarding your organization and its software assets is invaluable in the long term.

    — Pete Chestna

  • DevSecOps: How Security Teams Can Better Support Their Developer Counterparts

    DevSecOps: How Security Teams Can Better Support Their Developer Counterparts

    Much of the conversation around digital transformation revolves around technology. But the new wave of technology this era has ushered in has also made a big impact on the way organizations, and the teams that comprise them, function.

    This impact on corporate culture has paved the way for the widespread adoption of DevOps, which has broken down silos between developer, quality and operations teams and streamlined the software development process. The next step? Integrating the security team to ensure teams are shipping software that’s actually secure.

    Here are a few ways security teams can better support their developer counterparts:

    Understand How Software is Being Made

    Development teams are under increasing pressure to ship software fast and frequently. Security teams should identify ways to help developers keep up with the rapid software development life cycle (SDLC), while making sure security isn’t sacrificed for the sake of efficiency. Understanding the SDLC for your company is key to finding ways to help that make sense. Have discussions with your development leaders and influential developers to find some ways to win. Create a pilot program with a friendly development team and pour all of your effort into making them successful. Nothing breeds success like success.

    Act as Consultants and Partners

    Developers are taking on more responsibility when it comes to the security of the code they write, which has alleviated some of the pressure put on the security team to secure an entire organization. This has changed the way security teams function and given security professionals the opportunity to act as consultants to their peers in other departments.

    Security team members should approach their developer counterparts with an attitude of enablement. Offering security best practices, problem-solving strategy and general advice will help developers become more confident in their ability to secure the software they build.

    Base all of the above on the security problems they actually have. Don’t preach. Use data from your own application scanning to tailor training. Fill a room with pizzas and developers and talk to them over lunch about problems you can help them fix. Make it conversational. Ask them how they would like to be helped.

    Embrace Ongoing Learning

    Developers have a lot to learn from their security counterparts, but developers can teach security professionals a few things, too. Setting up peer-sharing sessions where both groups can learn from each other will foster an environment of collaboration within the enterprise. Security teams can share threats related to code and specific programming languages and help developers think more like hackers. Developers can share insight into the SDLC and best practices for using code components.

    Combined, the security and development teams should also request support from the leadership team in offering additional educational resources and training.

    Breaking down the silos between development, quality, security and operations to create a true DevSecOps culture will take adjusting on all sides, and it all starts with people. Highlighting the benefit of working together (increased security, streamlined processes and ultimately a better product) is the best motivator.

    — Pete Chestna

  • How Developers Can Take a More Proactive Approach to Security

    How Developers Can Take a More Proactive Approach to Security

    Developers tend to get thrown under the bus when it comes to application security, but recent data shows that developers do, in fact, care about security. Take mitigation for example. Developers don’t try to rig the system by rejecting findings as false positives or as mitigated by design. Developers documented mitigations for just 14.4 percent of all flaws found by CA Veracode’s platform in the past year.

    Still, IT and development professionals shouldn’t wait for a major breach to occur to uplevel their security skills. Here are a few ways developers can shift their approach from reactive to proactive.

    Seek Out Alternative Education Options

    The education path for IT and development professionals has some serious holes, especially when it comes to security. A whopping 76 percent of IT leaders report that they weren’t required to take a single security course in college. Many technology professionals are entering the workforce without a cybersecurity education, thus requiring them to learn their most crucial skills on the job rather than in the classroom.

    Across industries, online learning has emerged as one of the most valuable resources for working professionals who want to learn new skills. Online education is flexible, personalized and covers a wide array of subjects. The impact is clear: Simply by completing basic online learning courses about common vulnerabilities can help a developer improve their fix rate by an average 19.4 percent.


    Related Content:

    Cloud Services Demand Security Up the DevOps Stack

    CA Technologies Survey Uncovers DevSecOps Challenges


    Many times, developers are forced to take education into their own hands. Sixty-eight percent of IT decision makers report that their organizations don’t provide adequate security training, so they must find a way to fight for educational resources. Teaming up with security colleagues to make the case to the C-suite is one way to do this. A two-pronged approach could make a difference when asking for increased training budgets.

    Be Aware of Open Source and Component Risk

    The industry is facing a dilemma in securing the software supply chain. As development processes become increasingly automated, a lot depends on how well development teams can piece together open source components with their own handwritten code. This practice increases efficiency and lowers technical debt, but opens new doors for hackers.

    Open source components usually carry their own set of vulnerabilities and risks. In the past year, the majority (87.6 percent) of Java applications scanned by CA Veracode suffered from at least one component-based vulnerability. Many organizations either aren’t aware of these vulnerabilities or don’t even know what components make up their software products.

    Beyond lack of awareness, consistency in patching is also a problem. Once a development team integrates open source components into their code, they rarely update when security patches are released. Attackers frequently jump on newly disclosed vulnerabilities to target victims that fail to update fast enough, so thorough patching is crucial.

    Simply put, teams must bring a better discipline to the use of code components. Finding new ways to monitor, track and manage open source components in code is one of the most impactful activities developers can participate in to ensure secure software.

    Leverage Security Teams as Consultants

    As DevOps practices spread and more organizations require developers to do their own security testing, the role of the security team is evolving. Security professionals are becoming more like consultants that can uplevel developers’ skills with advice on best practices, strategic planning and individual coaching. This is where the idea of DevSecOps comes into play.

    To bridge the gap between development and security teams, attitudes need to adjust on both sides. Security teams must begin approaching developers with an attitude of enablement and developers must be willing to team up with colleagues that have a hacker mindset and expertise in understanding threats to the organization.

    Developers who see security experts as a resource rather than an opponent can make significant improvements to the security of their software application portfolios. Developers who paired their vulnerability findings with remediation coaching from security experts saw an 87.6 percent better fix rate than those who received no coaching.

    When it comes down to it, both security and development teams should try to be more proactive. If both sides commit to breaking down silos and learning from each other, they will find that DevSecOps is the best way to ship software both quickly and securely.

    — Pete Chestna

  • DevOps in the Age of Digital Transformation

    DevOps in the Age of Digital Transformation

    Digital transformation is one of the hottest buzzwords in the technology industry today. While it tends to be overused, the term does represent a widespread, ongoing movement that will set a standard for the next generation of enterprises.

    Digital transformation is all about keeping up with the pace of innovation and using technology to achieve business goals. A key differentiator in the age of digital transformation is customer experience. Consumers are increasingly engaging with brands on digital platforms, whether it be a website, social media profile or mobile app. The foundation of all these platforms is, of course, software.

    Agile software delivery is key because it helps organizations innovate faster and gets new software in the hands of consumers sooner. This requires new, more productive ways of working for enterprise IT teams. Development teams have already undergone several “transformations” in recent years, from the siloed waterfall approach to agile methodology and now DevOps. Software is the true differentiator in the age of digital transformation, and many companies are using DevOps to ensure their software meets the standard.

    Here are a few best practices for using DevOps to keep up with the pace of digital transformation:

    • Automate wherever possible. We no longer collect the work of multiple engineers over multiple sprints into a release. To out-innovate the competition in the digital transformation era, a team must release the work of a single engineer as soon as it is ready. This is usually accomplished through a CI/CD pipeline directly from the source repository through automated testing and then deployment into production, preferably without any human intervention. Choosing the right tools for your IT environment will cut costs, time and room for error.
    • Align the goals of development and security. DevOps isn’t limited to just the development and operations teams. Without security, all progress made in the digital transformation era is at risk to cybercriminals. The accelerating software development life cycle means little time for security analysis or penetration testing when the release candidate is ready to deploy. To ensure a piece of software is secure before pushing it to market, security standards must be included in the definition of “done.” Preventative scanning will not only train developers to write secure code, but will allow the software to pass the assurance tests included in any good CI/CD pipeline.
    • Measure ROI. Measuring the impact of DevOps can be extremely difficult and up to interpretation because of the focus on culture and processes. However, it’s important for DevOps teams to gain continued executive buy-in and dedicated resources by proving their value. The value of DevOps is determined in terms of achieving improved business outcomes. There are specific questions to ask to help determine ROI: How long does it take to release a code change? How long does it take for a product to reach a customer’s hands? The ability to continually deliver quality software faster results in a positive customer experience, ultimately improving brand reputation and revenue.

    While keeping up with the competition is necessary in the digital transformation era, putting customer experience first is how the true leaders succeed. By shortening the software development cycle, DevOps speeds the pace of innovation for an organization and helps earn customer trust and retention. Implementing these best practices can help a business use DevOps to place software and customer engagement at the heart of its digital transformation.

    — Pete Chestna

  • Executive Buy-in May Be Preventing DevOps Success

    Executive Buy-in May Be Preventing DevOps Success

    A common misconception in the executive suite is that an organization can reap all the benefits of DevOps without fully embracing the change necessary. That’s understandable, given that a DevOps transformation is a lengthy, costly disruption for companies of all sizes. DevOps requires businesses to transform, from team organization to culture to development processes. This shift often sparks reallocation of power and influence, which sometimes can make high-level executives uncomfortable. While most companies have begun to recognize the overall business benefits of DevOps, few are fully committing to such a large undertaking. As a result, a hesitant executive suite holds an organization back from realizing the full potential of DevOps.

    The key to successful DevOps implementation has four facets. Executing against one element just isn’t enough—an organization must combine all of them to realize the benefits of DevOps:

    • Training: Once executives have educated themselves on the importance of DevOps and accepted the disruption that comes with it, they must make sure the individuals are properly trained. Everyone involved needs to be open to learning new skills and new ways of functioning. A big part of DevOps is breaking down team silos, so individual contributors need to be willing to work across functional boundaries.
    • Tools: DevOps adoption can be viewed as a cultural and methodological change, and therefore teams also need the right tools that help them work together to create scalable and secure applications efficiently. The executive suite should invest in platforms that support automation and collaboration.
    • Support and determination: To provide support and guidance throughout the shift to DevOps, organizations should consider hiring a DevOps expert or bringing in a third-party consultant. This person can help the executive suite map out a DevOps strategy and help train the teams involved. Lack of expertise is one of the reasons businesses often fail to complete a DevOps transition.
    • Cross functional and accountable teams: A DevOps team should have all of the resources necessary to implement and deliver functionality to the customer. They should also be accountable for operating and supporting it.

    Another important consideration is security. The CISO and security team are responsible for security in most organizations, but developers need to understand the critical role they play in creating secure applications. They need to be accountable for the security of the software they write. It’s up to the security team to train and nurture them until they are self-sufficient. The development organization as a whole must be willing to make security part of the annual goal-setting process and to report on progress transparently at each level of management.

    Every DevOps implementation begins with education, from management to the individual contributor. Educational resources increasingly are available as DevOps continues to gain momentum in the industry. If faced with a hesitant executive suite, teams should leverage proof points from other companies that have successfully implemented DevOps. Leadership should be ready to measure, experiment, iterate and, most importantly, stick with it. When armed with the right training, tools and support, organizations can gain a competitive edge with DevOps.

    — Pete Chestna