Heads up! To view this whole video, sign in with your Courses account or enroll in your free 7-day trial. Sign In Enroll

Introduction to Application Security

Well done!

You have completed Introduction to Application Security!

Sign up for Treehouse Back to Library

Trusting 3rd-party Libraries

3:32 with Alena Holligan and Jared Smith

Before you import another person’s library, or install new packages, always be wary of the dependencies it can add, especially the security issues that may come with it. Just because a package is open-source does not mean it’s secure.

New Terms

Pen Test or "Penetration Tests" are used to evaluate the security of computer systems. A methodical approach is required to maintain both the integrity of the results and the stability of the systems being tested. Read more from the SANS Resources.

Red Team Testing or Red Teaming, is a process designed to detect network and system vulnerabilities and test security by taking an attacker-like approach to system/network/data access. This process is also called “ethical hacking” since its ultimate purpose is to enhance security. Ethical hacking is an “art” in the sense that the “artist” must posses the skills and knowledge of a potential attacker (to imitate an attack) and the resources with which to mitigate the vulnerabilities used by attackers. Read more at SANS.

Further Reading:

Npm Left-Pad Incident - Wiki

Trusting 3rd-party libraries on Treehouse:

Other reading about trusting 3rd-party libraries:

Understanding the security risks of third-party scripts, by Nick Merritt - Halo Security

Related Discussions

Have questions about this video? Start a discussion with the community and Treehouse staff.

Sign up

    Related Discussions

    Have questions about this video? Start a discussion with the community and Treehouse staff.

    Sign up

    Updating and patching your systems can be hard and 0:00
    painful, especially when you want your systems to still work after updates. 0:03
    However, the patching process can be much easier if you limit the number 0:08
    of third-party libraries and services that integrate with your application. 0:13
    For every third-party service you use in your core application, 0:18
    you put your trust into the developers and 0:22
    maintainers of those services to not expose security vulnerabilities. 0:25
    If they do, and trust us, they do very, very often, 0:30
    your application and all other applications that rely on that service 0:35
    can be vulnerable to all kinds of problems depending upon the actual vulnerability. 0:39
    For this reason, you should be extremely vigilant when relying on third-party 0:46
    packages for the core functionality of your application. 0:50
    It can also be dangerous to use third-party packages for 0:54
    a functionality you could potentially build yourself. 0:57
    Here are a couple of examples of trusting third-party libraries gone wrong. 1:01
    Left-pad was a Node.js package consisting of less than 50 lines of code to 1:06
    pad a string with characters. 1:11
    Though not a security risk, when left-pad was removed from the Node js package 1:14
    repository, it broke hundreds of thousands of applications. 1:19
    Malicious people will often add packages to package repositories 1:25
    that have names very similar to a popular package. 1:29
    Inadvertently, users will download the wrong package 1:33
    if not paying close attention. 1:37
    This allows the malware to run inside their application, 1:40
    again, potentially exposing the private information of their users. 1:44
    To prevent these issues, you, as a web developer, 1:49
    should consider the following before using a third-party service. 1:53
    Can you build the service or functionality yourself? 1:57
    Never write your own cryptography. 2:01
    Instead, you should be using bcrypt. 2:03
    There are people dedicated to cryptography that have a lot more experience than 2:06
    you or I, and their cryptography has been validated by millions of people. 2:11
    Would building it yourself introduce more risk than using a third-party service or 2:16
    library? 2:21
    If you can't build it yourself, or 2:23
    the risk is larger if you do, take the time to evaluate the packages you choose. 2:24
    Here are some questions you should ask when evaluating a package. 2:30
    Do any major companies endorse it, or did they build it directly? 2:34
    How many downloads does it have? 2:39
    The more the better. 2:42
    When was the last time it was updated? 2:44
    The sooner the better. 2:47
    How many contributors does it have? 2:49
    How many open issues does it have? 2:51
    How many open pull requests does it have? 2:54
    Is there a decent amount of test coverage? 2:57
    It doesn't have to be 100%, but it should be significant. 3:00
    Are there any clear warnings or notices in their readme or 3:04
    docs that say it isn't secure or not meant for production? 3:08
    Has the service undergone a security review, red team, or pentest? 3:14
    In general, 3:20
    don't use a third-party service if you can write it yourself easily. 3:20
    And if you do use third-party libraries or services, 3:24
    evaluate them in depth before using them. 3:28

    You need to sign up for Treehouse in order to download course files.

    Sign up

      You need to sign up for Treehouse in order to set up Workspace

      Sign up