Author: Joseph Feiman

  • Five Tips to Approach DevSecOps Training

    Five Tips to Approach DevSecOps Training

    Developers are on the front lines when it comes to protecting their organizations from cyberattacks. As we’ve seen with the hacks of Monster.com or the Fortnite vulnerability, 2019 has been a trying year for organizations who have failed to protect their applications and websites.

    With an increase of cyberthreats today, it is vital that organizations and developers incorporate standard security protocols within DevOps, a practice known as DevSecOps. Whether exploring these practices around security training, skills, metrics and more in the industry, it’s important to understand how each group fits into the security process.

    Here are five top tips for security training to successfully implement a DevSecOps strategy.

    Recognize Security is a Shared Responsibility

    Many departments throughout an organization make the mistake of thinking the responsibility of keeping their organization secure lies solely with the security department. However, with nearly 200 cyberattacks happening every hour, it’s important everyone gets on board in protecting applications and networks. As the creators behind our modern-day websites and applications, it’s especially important for developers.

    DevOps and security teams need to be taught how to approach security jointly. When approached separately, it is impossible to achieve DevSecOps. Without DevSecOps, the applications and websites used by consumers everyday will not be secure, and there could be security, quality, legal and reputational implications. Security is now being seen as a fundamental aspect of a consumer’s decision, and consumers gravitate towards brands that are more secure.

    Ensure the Entire Development Team Understands Common Cyberthreats and Application Vulnerabilities

    In today’s world, it is especially important for development and operations specialists to understand application vulnerabilities, and best practices to avoid those vulnerabilities. Without this knowledge, developers and their teams won’t understand just how important security is until it is too late.

    Staying on top of the evolving threat landscape, however, can be a daunting task. After all, there is a lot of information out there. The first step to staying informed is to compile a short list of reliable, valid security news sources. Another step could be creating an internal method for the security team to share details on new vulnerabilities with the development teams.

    Unfortunately, hackers tend to exploit vulnerabilities that were accidentally created by DevOps. In order to fight this, DevOps specialists should be made aware and trained in secure programming, secure application configurations and use of secure frameworks.

    Incorporate Just-in-Time Learning into Your Strategy

    Traditional training courses, especially in the security sector, have some challenges. Many universities and free online resources will offer courses online in cybersecurity. While this can be beneficial in continued training, it can take a significant amount of time to complete the course, and some projects require a certain level of knowledge sooner rather than later. Most courses need to be taken well in advance of a project, where the acquired knowledge will then be applied.

    For example, say developer X just started a course in how to protect from vulnerability Y. At the same time, developer X has a project with code that could be vulnerable to Y due in the next two weeks. With the tight deadline, developer X may not be able to get the knowledge they need to be able to protect their application in time.

    In order to combat this, the security industry now offers real-time learning. Otherwise known as “just-in-time learning,” this approach is giving the employees the much-needed information exactly when they need it. These courses usually come hand-in-hand with using application security testing technology, enabling rapid remediation of a detected vulnerability. For example, when a new security technology is introduced to the organization for development purposes, just-in-time learning would involve developers learning to use it on current projects in real time.

    Avoid Making DevOps Specialists into Security Experts

    While it is important for DevOps practitioners to have knowledge of security best practices, it’s important to remember they should be focusing on their task at hand: creating applications. Security transparency is a critical condition for security adoption by the DevOps team, so it is important the technologies developers rely on are transparent. However, security technologies should not distract DevOps specialists from development and operation. DevOps specialists should be security aware and applying their best security development practices.

    The technologies should test applications and get results to those who need them. DevOps practitioners should then use those results, without having to worry about learning and running sophisticated security detection and protection technologies.

    Remember the Goal is to Educate, Not Embarrass

    Even when using the above tactics, it is still quite possible developers will miss a vulnerability and SAST, DAST, IAST and SCA technologies may discover it first. When this happens, it is easy for DevOps specialists to become embarrassed because their managers see the results first. No matter the experience level, developers will likely at some point make a mistake that can cause a vulnerability–which ultimately gets back to their supervisors and peers.

    Rather than feel embarrassed over the security technologies, developers need to learn how to utilize them to their advantage. For example, modern SAST allows developers to conduct tests out of an IDE and return the test results to the same one. The developer is the only one who will see these tests, and therefore, they can be the one to review and remediate a problem. This process helps eliminate the shame developers feel, and it will instead be replaced with education, security and confidence.

    Cyberthreats are not going away, and all signs are pointing to the fact that they are only going to get more advanced in the future. However, with adequate training and cybersecurity education for development teams, organizations can stay ahead of adversaries and fortify their application security.

    — Joseph Feiman

  • The Challenge of Securing Open Source Applications

    The Challenge of Securing Open Source Applications

    As enterprises have increased their reliance on applications over the years, there has been a significant rise in the use of reusable software components such as third-party libraries and open source code. This makes perfect sense, as this development method makes it possible to add value to applications and other software offerings quickly and easily. After all, why reinvent the wheel when supposedly well-tested and proven software components are readily available?

    As a result, open source code has become a vital part of software development for most organizations. Today, nearly 70% of every application is comprised of reusable software components, including open source software. At one time, open source software was considered too risky for commercial use. That is not the case today, however, as even major corporations are making use of open source components to innovate and deliver applications to market rapidly.

    While enterprises have gotten very good at using open source to speed the application development process, they have not yet figured out how to do so without inadvertently introducing vulnerabilities into their code. This is due in part to the fact that as more enterprises increase reliance on applications, they fail to implement application security into the software development life cycle. Consequently, as the adoption of open source software continues to grow, the likelihood of applications inheriting vulnerabilities is higher than ever before.

    This is evidenced by the fact that, according to my company’s research, unpatched library vulnerabilities make up 21% of all application vulnerabilities, by far the most of any type. In fact, nearly 20% of the inquiries we answer are related to unpatched libraries, which is almost on par with injection vulnerabilities.

    That is why it is imperative for development teams to stay up-to-date with open source library maintenance and updates.

    Software Composition Analysis

    The right way for organizations to track their open source components is through a set of technologies known collectively as software composition analysis (SCA). These technologies, which arose out of a need to automate the open source management process, provide organizations with visibility into their open source inventory. This allows them to identify third-party and open source components integrated into their applications.

    Using SCA, organizations can determine easily if any of their applications are relying on a vulnerable library, if any libraries are out of date and whether licensing is legal/proper. SCA helps them identify multiple types of risk introduced by third-party and open source components. These can include known vulnerabilities, intellectual property risk and technical debt related to component age.

    It’s important to remember the use of open source software code is not a problem in and of itself. On the contrary, it has been an essential part of the recent innovations in software development, and, in fact, it is no riskier than proprietary or commercial off-the-shelf offerings.

    Problems arise only when organizations fail to be proactive in identifying and managing security and license risks associated with open source code. This may occur in part because it is assumed that, as with commercial software, updates, patches and information are pushed to the user. But that’s not the case in the open source world, where the onus is on the user to keep track of these things.

    It takes diligence, but in the end, the only way to mitigate both the security and legal risks associated with your open source code—and to fully realize its benefits—is to track every piece of it. Today, SCA is the proven way to help you do that. By incorporating SCA into the development process, developers can capture inherited vulnerabilities early enough to prevent them from being introduced. Of course, it should go without saying, but it’s not enough to just find vulnerabilities; you also must fix them. The most typical remediation is replacing vulnerable components with the non-vulnerable ones.

    Considering most application code is now open source, and attackers are going after vulnerabilities in open source more than ever before, SCA should not be an afterthought. It needs to be an integral part of any organization’s application security and secure DevOps processes.

    — Joseph Feiman