What Do I need to Know about Security? @ All Things Open 2022 (Raleigh)

Speaker: Melissa McKay, Developer Advocate & Docker Captain @JFrog

December 28, 2022

< 1 min read

Title: Confessions of a Vulnerable Developer: What Do I Need To Know About Security?
Abstract: The lines between development, operations, and security have become blurred. Originally a way to divide and conquer, we are coming to realize that the resulting silos from separating out the different types of expertise are not in the best interest of anyone that uses software products and services. Security, especially, is something that needs to be considered as early in the software lifecycle as possible. But what does this mean for developers? What does a developer need to know about security and what are the practical implications? It can feel overwhelming at first, but don’t fret! Join Melissa McKay to learn some security basics and about free and open-source tools to add to your developer’s toolbox. You will leave with the knowledge that will provide immediate value, allowing you to continue coding with confidence as well as improve the security of your software.

Find more info about All Things Open:
On the web: https://www.allthingsopen.org/


Melissa McKay

    Melissa McKay

    Melissa is a long-time developer/software engineer turned international speaker and is currently a Developer Advocate on the JFrog Developer relations team, sharing in the mission to improve the developer experience with DevOps methodologies. Her background and experience as a software engineer span a slew of languages, technologies, and tools used in the development and operation of enterprise products and services. She is a mom, Java Champion, Docker Captain, co-author of the upcoming book DevOps Tools for Java Developers, a huge fan of UNconferences, and is always on the lookout for ways to grow and learn. She has spoken at Kubecon, DockerCon, CodeOne, JFokus, Java Dev Day Mexico, the Great International Developer Summit, and is part of the JCrete and JAlba UNconference teams. Given her passion for teaching, sharing, and inspiring fellow practitioners, you are likely to cross paths with her in the conference circuit — both online and off!

    Video Transcript

    today and please visit our booth when we’re done here I also have some awesome
    stickers you cannot leave without I have all kinds of fan club stickers here I
    have um Dr Strange stickers I have for any Princess Bride folks I have Diego
    Montoya stickers i’ve got Star Wars sticker and super frog stickers so come
    see me after if you’d like any of those all right first of all just a little bit about me I am Melissa McKay
    um first and foremost I am a developer I have been for over 20 years it’s been a
    privilege to become a speaker about two years ago let’s see about when
    everything shut down I decided to become a developer Advocate because I was ready
    to travel obviously that didn’t happen so I got a lot of uh practice on zoom
    and doing um video calls and and video conferences online conferences that kind of stuff
    um I also am an author I did spend some time the last couple years with some Co colleagues of mine we put together a
    book called um devops tools for Java developers my
    background is primarily Java server side I became a Java champion and also a
    Docker Captain so I like to keep up with the latest and greatest coming out of the container world I do have a talk
    tomorrow as well talking about container standards giving you an introduction to that
    um today though we are going to talk about security and
    um this is my book by the way um when I started this
    talk writing this I realized that what I care about security has a lot to do with
    how much I care about devops and as a developer
    um I was posed this question on a panel once this is a little bit uh different
    um why should a developer care about security versus why should a developer care about devops turns out there’s a
    lot of similar reasons um but I mean we’re already being asked to do a lot developers seem to be taking
    on a lot more and more I know that when I joined a devops team I was pretty overwhelmed with all of the new tools
    and everything that I needed to learn I immediately got you know
    put on making sure that our pipelines were up and running for a brand new project
    making sure that our build server was behaving the way it was these are all skill sets that I did not have
    immediately as a developer there were new ones that I had to accrue over time so when we talk about security it feels
    like just one more thing added to the pile and the first thing you know that I think of is isn’t this a security team
    expert is it their job is it something that Ops takes care of and as it turns
    out it’s something that we all need to care about everyone on the team and there are things that developers should
    be aware of and should be prepared for as they develop their code
    so yeah instead of uh blaming you know the other guy or assigning the other guy
    all the work or when things go wrong you know pointing your fingers elsewhere uh we do have some responsibility in this
    and let’s talk a little bit about what the consequences are when we don’t pay
    attention to security you’ll probably hear a lot of these and
    and probably have if you’ve been to security talks you hear about these um over and over and over again these
    attacks that have happened um this one it was a pretty serious one Equifax Equifax breach it happened uh it
    was continuous it happened through March through July of 2017 that was quite a
    while ago but they’re still paying money out for this um they were fined quite a bit lots of
    cleanup costs 1.4 billion in cleanup costs actually 1.38 billion in consumer claims
    um 143 million customers and this was just because of an Apache
    struts vulnerability that existed that people knew about but they didn’t get updated in time before it got utilized
    by hackers here’s another one solarwinds familiar with this one this was a supply chain
    attack this happened when a product an updated version of this software went
    out to a bunch of customers and it turned out to not be a legit version of this software and this is
    pretty serious uh it added about 4 000 lines of malicious code to the Orion
    platform dll and uh this binary was switched on their CI system so
    apparently there were some security issues there 18 000 customers received this
    particular update that had a back door
    then we have log for Shell this is the latest and greatest as a job as a Java Dev I was really concerned about this
    one you know going through all of my projects making sure that I was not utilizing an older version of this
    all of this uh has cost a lot of money and a lot of the reason behind it is
    because uh our data is very very valuable so a lot of money is going into
    data breaches Equifax had a pretty severe uh fine for this they started out
    at agreeing to pay 575 million dollars up to 700 million dollars if that first
    amount wasn’t enough to cover all of the claims and what you might not have known is they already were fined in the UK 500
    000 pounds in addition to that so pretty big deal some other big ones there was
    the Home Depot had a data breach in 2014 they had to pay out at least 134 and a
    half million dollars to credit card companies and Banks as a result of that breach uh in 2016 they agreed to pay
    more money 19.5 million to customers that had been affected um so you can see this is continuously
    going on as far as solar winds we don’t know yet if any money is going to be
    coming out of that seems to be still in the works there could still be some money coming out from that breach
    another interesting one um December 2021 Capital One agreed to
    pay 190 million dollars to settle a class action lawsuit for a data breach
    they had and then in 2016 Uber had a huge data
    bridge this one was interesting because they didn’t tell anyone about it at first so they were fined a bunch of
    money for that and then once everything came out into the open they were fined more
    so pretty serious lots of money involved and clearly developers have something
    that they can do to contribute to a solution and this is a slide you know I’ve used
    before um for you know devops talks in the realm of devops and why should a
    developer care about devops is because of all of the processes that are involved all the communication that goes
    on with different teams turns out this is very similar to our security needs
    our security needs cannot just be limited to all the way at the left or all the way at the right it can’t be
    something that is just tacked on at the end um and I I came in at the tail end of the
    previous talk um uh he was mentioning that you know shifting left has some costs uh it
    absolutely does um in my opinion it’s necessary in some cases but there are appropriate ways of
    making this happen for developers that doesn’t have to be quite as painful
    so these are the four things we’ll be talking about a little bit I’ll start off with you know writing safe code
    managing our dependencies building our artifacts responsibly that was something
    that I learned through trial and error and then understanding protecting and maintaining the dove delivery pipelines
    that was something that was new to me as a developer before I joined a devops team I was often in the position of just
    writing my code committing it and that’s all I saw went over the wall someone else’s problem after that
    so uh because of all of these breaches and everything companies have started to
    clamp down on these problems they’re trying to educate developers a little bit more and several years ago I got to
    do security training at my company there’s a lot of third party um
    organizations out there willing you know to teach developers and give them a better handle on how to write their code
    better and I remember the particular program that I was a part of you chose the language that you usually wrote in
    and you would go through all of these exercises to learn all kinds of things I learned about cross-site scripting I
    learned about SQL injection I learned about ldap injection I learned about cross-site forgery request forgery and
    insecure cryptographic storage and I felt pretty smart after that
    I was pretty sure I knew what I was doing and was very happy with myself and continued on thinking I knew it all
    and clearly there’s a lot more involved than just writing code that is safe
    there’s a lot more around it um there’s a lot more resources out there now to describe the problems that
    exist as well this page I found it’s a a essay written by a group of folks for
    the owasp organization a wasp stands for open web application security project it
    is a non-profit Foundation that works with open source projects trying
    to improve security you know for all of us they try to keep themselves vendor
    agnostic and this article is pretty funny there’s several things in here that made
    me chuckle this essay was written in a way like how to write you know code that is unsafe as
    opposed to all the rules for writing it safely um these are some of the funnier points I
    loved the secure languages I’ve heard this argument before like oh I I program
    in Java we don’t have security issues and then you know lock for a shell happened and then uh or you know I
    program in rust or I you know I’m special somehow and don’t ever write
    code or using a language that has any issues obviously that is not true mixing
    languages I like this one too let’s see how many languages I can write in successfully and be able to know the
    security patterns well enough to be able to pass all of my security exams for
    every language I had this issue when I started writing Docker files for containers that was an interesting
    activity and we’ll look at a fake Docker file a little bit later and just kind of walk through some of the problems that I
    saw immediately here’s some more um I love this one relying on Security
    checks done elsewhere someone’s doing a security check somewhere so I don’t need to worry about
    it very nice and trusting Insiders
    um there’s a very real example of that malicious input coming from inside a
    company it’s a big problem and code wants to be free dropping
    source code into repositories that are accessible accessible by all within the company that one’s really interesting to
    me because for many many many years I used artifactory and I didn’t even know
    that artifactory was part of jfrog here I am working for jfrog now
    and um but as a developer I didn’t have the rights or permissions to really see what was going on back there
    in that system and as a result uh when I joined a devops team all of a sudden I
    realized I needed a place to put stuff and if you have one of those drawers in
    your kitchen that has just everything in it it’s got staples rubber bands glue a
    pair of scissors maybe sticky notes uh barrettes
    that’s what our repositories looked like because I didn’t understand the purpose behind it the purpose of keeping all of
    that organized the purpose of keeping one repository separate from another based on whether it’s a production
    repository versus a QA or test repository or registry these are all
    things that we need to consider when we’re setting that stuff up to keep ourselves organized and also to set
    permissions on these things that’s a pretty important uh I’ll touch
    on that a little bit later again as well all right I’ll let you go read the rest
    of that yourself if you like sarcasm excellent excellent essay
    first and foremost developers need to manage their software dependencies we
    don’t talk enough about dependencies in my opinion this is pretty important for
    us I know as a junior developer it might be something you don’t touch on for a while
    because I remember my first job coming out of college and as an intern was I
    was put on a project and given a script to build and run and that was it and I
    was just so excited to jump in to start developing a feature start fixing a bug I didn’t spend enough time understanding
    how that build was actually working under the covers
    how many of you use maven yeah Gradle
    npm ah scary
    pie pie okay cool uh this is yeah it is very scary
    um this particular graphic is pretty overused but that concept that software is potentially made up of a ton of
    components that a developer does not have first-hand knowledge of cannot be understated applications and services
    that are built today are more complex than ever generally good developers
    don’t want to reinvent the wheel we want to be as efficient as possible we want to get our stuff done I remember one of
    my bosses told me he his purpose was to hire lazy developers because they were
    the most efficient it turned out to be a pretty lazy developer so I did well
    the problem is many package managers like what we just discussed make all of this so easy for
    us we use them to collect everything we need behind the scenes um that includes Maven Gradle and PM
    Pepi Etc and sometimes we can get tripped up by transitive dependencies
    and unfortunately many pieces of software may still be whoops may still be suffering from the log for Shell
    exploit simply because the project doesn’t pull in that Library directly but it may be pulling it in as a
    transitive dependency indirectly there could be a level one dependency that is
    actually using that as its dependency
    and also uh that convenience of being able to use these package managers to just kind of handle all of that for us
    [Music] um they blind us to what’s actually happening how these dependencies are
    being pulled and where they’re being collected from unless you specify otherwise these package managers are all
    going to be collecting from public repositories unless you configure them
    otherwise this means there’s a ton of developers out there right now who are running Maven build clean on their
    machine and they’re hitting Maven Central directly same within PM they’re building their node application they’re
    hitting the public npm registry directly it doesn’t matter if their company is
    using artifactory if they’re using a Nexus or you know any of the others out
    there that are available to manage these dependencies for you if you don’t configure them it’s not just going to
    happen by Magic so here’s an example of where all of
    these actually pull from by default Docker is a big one too whenever you run
    a Docker pull it’s pulling from the docker public registry just be aware
    that that is what is happening unless you configure something differently
    um pretty easy to solve this you think like I said you can set up artifactory Nexus Harbor any of those and you can
    set those up to actually only pull from these public repositories when your
    particular dependency or package that you’re looking for isn’t already available or cached internally somewhere
    that sounds great except there’s a specific problem that
    is why you know I’m fearful for all of us using npm without thinking about it
    we’ve managed so far this has been around a long time this problem has existed forever but in 2021 Alex Burson
    did a really good job of writing up a description of what this problem is and it’s called the dependency confusion
    attack and it described how he was able to hack into Apple Microsoft and a dozen
    of other companies using a novel supply chain attack
    so description of that what that actually looks like is um here is a typical Json file that
    describes the packages that a particular project needs to build right I’ve highlighted some of these
    um notice that the versioning scheme for these indicates that anything greater
    than the version that’s indicated there would be acceptable in this case so if
    there’s an update available it’d be great to keep up with updates right we’re being more secure we want to keep
    up with these updates well here’s a problem what if the build for this project
    is configured like I described that if a package isn’t available locally then the
    default behavior is to reach out to the public registry that sounds okay but what if these
    highlighted package names are actually internal package names and they shouldn’t be available in a public
    registry and it turns out that anyone can publish
    a package to the public npm registry using any name that isn’t already taken
    so if you have internal package names and and they are not spoken for in the
    public registry there’s a chance that someone can create one for you
    and now you’re in trouble this is what that looks like you have a corporate library you intend
    to get someone publishes an awesome update and you get that one instead
    not legitimate and then you don’t know what’s going to happen when you pull that into your project and run it
    so one way to protect against this is to make sure that you do not ever go to
    public Registries for internal package names make sure that you don’t forget to configure that step by default that’s
    not how things work [Music] here’s another example of
    um just building other artifacts that can be a problem this is a contrived Docker file it kind of illustrates some
    of the problems that I’ve had myself with packaging applications that I’ve already created so this was new to me at
    the time building Docker containers using Docker files I very much knew how
    to you know take care of my Maven project my my Java project I made sure everything was you know internally
    sourced I had all of that protected but in the end I needed this to be in the cloud so I ended up wrapping up my
    application in this Docker image and if you go online to look for Docker
    files you’ll see stuff that looks very similar to this and the very first problem is that line one what I said
    about pulling from public registries that first line is pulling from the docker public registry if you don’t know
    what that parent image is how can you ever think that it’s safe
    make sure that anything you’re pulling is um you know at least spoken for or has
    documentation around it make sure you’ve done a dive into that image to make sure that it has in it what you expect make
    sure you’re scanning that image also make sure that you can source that parent image locally internally instead
    of constantly pulling it externally I know when Docker decided to you know put
    some limits on pull requests there were a lot of CI servers out there that were configured to just always pull from
    Docker hub and you might think well once the image is built you don’t have to build it again there’s caching but think about
    how a CI server works a lot of times we purposely wipe that cache because we want it to be built fresh so every
    single time everyone and did a commit a new image needed to be built it’s pulling from Docker Hub so a lot of CI
    servers had some troubles continuing their builds when that flow was cut
    um so make sure that whatever parent image you’re using Pull It in make sure that you have it
    uh two and lines two through four it looks like not only do we have a parent
    image we’re unsure of but it didn’t have everything we needed in it so we decided to throw some packages in there to make
    sure that our application that we really care about can run well notice there’s no versioning on
    this some of those packages may be old this is something that can be easily
    missed um you know during a review of the project you know making sure that you are
    responding to any um vulnerability notices or anything like
    that making sure that you update these images those additional packages probably should be put in to another
    parent image and and combined maybe um uh maintained by a platform team you
    know something that can be made available to all the developers that would be one way to manage those updates
    and make sure that the base image is actually something that’s okay to use
    line six is actually a really big efficiency and performance problem if
    you’re not using a git ignore file when I first started working with Docker files I didn’t know that I’d get a
    Docker ignore file sorry I didn’t know that that existed and it is very similar to a git ignore file in that when you
    have a copy statement like this and you’re copying a bunch of files from you know a working directory intended to be
    in the image in the end and available in the container when it’s launched you’re
    copying everything think about what you’re copying you could be copying test code you could be
    copying maybe even environmental configuration that shouldn’t really be
    in a production image you could be copying your dot get directory that’s
    probably not the best thing there’s a lot of stuff that happens there I noticed when I was going through
    this that my builds were taking forever and it’s because all of that material has to be passed to the docker Daemon in
    order to make it available during the build and that process takes a long time lots of unnecessary activity there
    and possible security issues if you’re copying things you shouldn’t be
    um number seven I see this a lot I see it in a lot of examples on line two of
    Docker files I remember using this specifically because in our case we had to install a
    some software that we had paid for and this is how we did it we grabbed the script from a link that they gave us
    just curled it in uh ran the script and then our proprietary software was
    installed the problem with this um no we were responsible enough to at
    least look at the script but how many times do you think this happens when no one’s even looking at the script they
    just run it you’re just provided with a curl statement and you just run it if you’re doing that probably not a good
    idea eventually what ended up happening happening with us because we ignored this for a long time is it our build
    failed and took a little research to figure out why our build was failing turns out this was no longer available
    it was being pulled from some repository that the company we were using it from
    didn’t use anymore they chose to do something else with it put it somewhere else that happens all the time so
    whenever you put your stuff that you need to build your project in the hands and responsibility
    of an external party just be prepared to have things fail randomly and the more
    you do that and the more different places the more problems you’re going to have so the very least bring that script
    in-house manage it yourself update it on your schedule and not on someone else’s
    schedule I don’t know if any of you get sick of having your computer keep popping up
    with you know this thing is updating now and this thing is updating now and I’m like I’m up here giving a talk I don’t
    want this thing to be updating right now right I want to have control of that so I know a lot of developers shut that
    down immediately I feel the same way about stuff like this stuff that I need to have
    reliability that is going to build on my schedule all right the last one
    uh line nine running is root you know obey that principle of least privilege
    and let that script only have the permission for what it actually needs
    um it’s you know fairly easy to set up a user and group and make sure that you’re you’re doing that
    those are just a few problems that I’ve come across pretty frequently in Docker
    files definitely not an exhaustive list but it’s a pretty good place to start
    so here’s um just to recap since I care about containers and Docker images so
    much make sure you’re using trusted or official base images don’t use bulky parent images use multi-stage builds
    that means making sure that you’re not including you know build tools and stuff into your image that’s really not
    necessary specify all versions of all packages that you need to include in your images use that Docker ignore file
    get those external resources internal manage them internally and do not run
    processes as root that last one there was a report that sistig did
    um Cloud native security and usage report it was out of 3 million containers that they were observing and 76 percent of
    them were running processes as root so I feel bad for hop you know harping on that one all the
    time but clearly we’re not taking that one seriously enough
    okay so dealing with dependencies and artifacts that we have built
    this is a slide that I see in our corporate deck quite often I don’t expect you to be able to see all the
    little things but this is just basically the software development life cycle all
    the way from the developer to deployment to production what this doesn’t include is like monitoring and everything that
    happens after you deploy to production but look at all these places where we care
    about dependencies and artifacts so this is step two this is a developer resolving dependencies
    uh this is you know getting these dependencies from remote repositories if
    necessary here’s another one this is our CI server again resolving dependencies doing its
    build every time you check in we’ve got one at the very end when we’re done with
    building we now have this artifact we need to put somewhere we’ve got to deploy it somewhere so that it’s
    available for later use and then that later use could be either you know providing it for distribution
    elsewhere or actually deploying it to a production machine or service
    so technically everywhere you see one of those green connecting lines that’s an
    opportunity for disruption in your build and the delivery process so we need to pay attention we’ve got to talk about
    this more dependencies and our artifacts and how they move through the system there’s efficiency issues as well as
    security issues that we need to pay attention to thank you
    this is a simplified version of that pipeline in the previous slide so where we should be concerned obviously in
    development we just talked about how I’m in my local development environment and I’m pulling stuff directly from Maven
    Central and pulling stuff directly from npm registry all of that
    um sometimes we need to be able to reproduce a build in order to fix a bug
    that we’re looking at in production so we care about where our dependencies and where our artifacts are coming from this
    is what we do every day we troubleshoot we repeat we build and design and do it all over
    again continuous integration we talked about that some CI servers are misconfigured
    in that they continuously reach out to public repos when they really should be
    um you know only doing that when it’s not cached or when uh the artifact isn’t
    already available in the system and then ultimately we want to store our
    artifacts on a build success we need to consider where we’re putting them
    by the time we get to testing we need to move those artifacts around they should not be rebuilt at this point once you’ve
    built it in continuous integration that’s it you take that artifact and you promote that artifact through the rest
    of your pipeline until it either breaks doesn’t pass a test or any of any of that and then finally
    it can be promoted to production where everything has been checked off everything’s green
    that is our release when we actually you know get a release put together we want to
    make sure we’re collecting the correct artifacts that we’re wrapping them with you know a bundle that makes sense and
    then ultimately we want to be able to deploy these artifacts um and not accidentally deploy something
    that maybe was inadvertently put in a repository with everything else like
    that junk drawer in the kitchen we want to make sure we’re getting the right artifact
    so yeah everywhere you see this green connecting line can potentially be a
    problem um this is where or you know specs like
    um the salsa have who has heard of salsa worked with it at all okay it just
    basically describes um supply chain levels for software
    artifacts it’s basically best practices how well do you handle all of these
    behaviors and everywhere where you see this red triangle is potentially an
    issue now as a developer we’re going to pay more attention to the stuff closest to us which is all the dependencies that
    we resolved when we’re actually doing our builds and then our source code and
    then our CI servers we definitely are going to be paying attention to those
    one of the most crucial areas to harden is your build process during continuous integration make sure that the
    dependencies you’re pulling in are exactly what you expect them to be they need to be the expected version
    um you need to verify they are a trusted dependency and not a malicious package that happens to have a similar name
    so remember that solarwinds hack we were just talking about apparently their update server they got hacked at the end
    when they’re ready to provide their production asset to all of their customers that step got interrupted and
    their update server could be accessed publicly with the password solarwinds123
    if you’re new to this landscape you’re going to make mistakes I did some trial and error like I showed with that Docker
    file earlier the most important thing that you can do is make sure that you can respond to problems quickly just
    like as developers we’re taught that we’re never going to be able to produce a hundred percent bug free application
    if you do you aren’t doing enough testing it’s just not possible it’s not feasible
    it’s all a balancing act but when you do find vulnerabilities when there are
    problems and it will happen make sure that your process is such that you can respond immediately quickly get your
    stuff updated this this is like maintaining a house it’s never done there’s always the yard to clean up when
    I get home I’ve got to clean up my yard for winter looking forward to that there’s a roof to repair if you have
    hail storms like where I live there’s hot water heaters that blow up these things do and will happen same with
    software so make sure you’re spending the money to keep everything maintained keep your versioning up make sure that
    you dedicate time in your process to update all of your
    packages just to make sure that you’re keeping ahead of these problems
    so quick review how can a developer improve security all these things we can focus on writing safe code make sure
    that you’re taking advantage of the resources available to learn about your particular language that you work with
    what are some of the patterns to be concerned about make sure that you’re managing your dependencies appropriately
    building your artifacts responsibly like with that Docker file we just looked at and then understanding protecting and
    maintaining your Dev delivery pipeline that means updating your stuff don’t get
    complacent and think that if it’s just not broken I don’t have anything to worry about you may have some money to
    be paid out if you’re thinking along those lines really quickly some tools that a
    developer can use in real life this is frogbot very cute very cool open source
    project it uses jfrog x-ray for scanning for vulnerabilities this is a way for you to
    manage vulnerabilities in detecting them at the point where you’re committing into your source code
    another one I use this one frequently whenever I’m utilizing a new Docker
    image or creating one or making modifications to a Docker file that I’ve been working with I’ll scan it locally
    using Docker desktop jfrog has a plug-in there that can help you with that
    there’s lots of other scanners available there’s no excuse for us not to be doing this paying attention to the changes
    that we’re making locally in our environment before we even check in
    this is another open source project that is dealing with supply chain security and I’m wearing the Persia t-shirt today
    we have some at our booth too this is a project that is now incubating in the CD
    Foundation how many of you have heard of the CD Foundation
    how many of you have heard of the cncf okay so the cncf is a cloud native
    Computing Foundation generally people have heard of that one more it’s huge it’s behind kubecon a lot
    um the CDF is continuous delivery foundation and it focuses mainly on the
    open source projects that are involved in continuous delivery so a little smaller substant these two organizations
    are sister organizations they’re underneath the Linux Foundation there are a lot of opportunities to be
    involved in the projects that are coming out of here Persia is one of them Persia is an open source project that is
    creating basically a decentralized package Network that has full provenance over
    all of the artifacts that you would depend on as a developer it’s starting with Docker containers making sure that
    um you know you can trust that you’re getting a Docker container that is or a
    Docker image that is what you expect it to be and it basically has to it works
    on this decentralized idea so that there are multiple trusted nodes that have to
    agree that this particular artifact is what it says it is in order to prevent
    you know any nonsense with someone trying to insert a package that is not legitimate
    this is also meant to work for languages like go that actually are
    built directly from source so one idea is that this decentralized registry
    would take that source several trusted nodes will build that
    source and make sure that the hash is the same if it is it gets marked as okay
    and future use of that artifact is considered safe
    um interesting just trivia on the Greek origin or Persia it had to do with you
    know um lighting messages multiple messages between multiple mountains making sure
    that everyone was in agreement that uh you know things are happening the way they should
    we talked about the security model already a little bit there’s more information about Persia at the booth
    this is something that I’ll be talking about more and more as we get more and more developed with this project we are
    looking for contributors oh one more thing I wanted to share
    this is really cool
    and then I’ll open for for questions um this is my IDE I use IntelliJ it’s my
    favorite um and this what we’re looking at here is just a pom file of a project that I
    pulled down it’s a spring boot project that I’ve been playing with toying with trying to make it better
    and one of the things that I’ve hooked up here is is a plug-in it’s a security
    vulnerability plug-in that tells me if there are any problems with the packages
    and libraries that I’m bringing in to this pom file what’s really cool about this is before I even make any changes
    or check any of this code in I know for a fact there is a better version of
    spring boot starter parent just put 2.7.4 I’ll update it and I’ll
    take a look at it and I can tell live that there is definitely improvements not perfect but it’s improved this is
    something a developer can do right in their development environment before they even check their code in it it
    helps helps the whole process so that this doesn’t get flagged immediately all
    the way at the end in production so just an example of what can be done
    this is the jfrog plugin jfrog IDE plugin and it supports multiple IDs not
    just IntelliJ it’s just my choice for today
    yes yep publicly available um it does operate on x-ray which is a
    product of jfrog but it is a free there is a free usable version of that
    which is nice if you’re gonna you know just as a developer you can set up your
    own instance and be able to use that to get a majority of your problems covered
    it’s interesting to analyze too if you have a full-on security team it’s nice
    if they have policy set up so that some of this stuff gets filtered for you before you even see it because really as
    a developer seeing all this red can be a little overwhelming and some of it isn’t applicable to what you want to do so
    making sure that you’re paying attention to the analysis which that’s all right that’s also provided as part of the
    explanation in the plugin um you’ll be able to tell if uh you know
    through context if this is something that you should really be concerned about or not
    all right that is it that’s all I have for you today
    um if you’d like to contact me I am at Melissa J McKay on Twitter
    um I am in the process of getting another social media account I bet a lot
    of you are as well um so I’ll start putting that in my slides in the future but for now this is
    where you can find me um don’t forget stickers Cool J frog stickers