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

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