Whodunnit - git repository mysteries

uh our next uh speaker is Natalie sersa uh the title of her talk is who done it a get repo mystery please uh welcome [Applause] Natalie hate to say everyone was wrong here but hi my name's Taylor and I was born in 1989 except that's only true in GitHub and on that terrible disappointment for everyone here let's learn about what you can reliably know about who did what and in a get repo hi I'm actually Natalie these are my social accounts uh more importantly all the slides will be here probably next week I do appc and software Factory stuff well what's now called software Factory with FEDS and defense industrial folks so that's uh all the the

commercial sector that that really supports our Direct Federal um users so nist uh itar cmmc fed ramp all those fun things kind of where I live day in and day out um and because of that I have been in the hot seat more than once and I've walked a lot of people in that hot seat way more than once through code Audits and really hard questions about what we can prove that we know in a code base uh oh snap what's a code audit so normally when I open up these conversations a lot of people are like well get does Version Control tracking duh that's what it does it gets a little harder once we

start adding more things here like oh my infrastructure is code how do I prove these changes uh we had an incident we're leaked secrets to blame or more importantly did these attackers you know compromise our code did they make changes how can we know and tell this uh we're making an acquisition can can you even purchase the software what does that due diligence process look like you work with foreign Nationals uh on some contracts and some programs being affiliated with a foreign government in any way shape or form you need to at least be upfront with that so what code are these people changing and when uh our software Factory must carry some sort of compliance certification or this

software is in scope for Saran Oxley so if you're starting to talk about Public Finance uh your publicly traded Finance um you life gets a little hard and some of these audits can be self-attested some can be third party so you're trying to explain things that happened a year two year three years ago when you joined the company six months ago everyone who was there left what can you know so talk a little bit about where we're going today and I definitely had way too much fun with mermaid diagrams the process that we're looking at is human being changing files that are then stored in a git repository on a local local machine and endpoint or a

developer workstation and then pushing those into some sort of central remote so GitHub gitlab bitbucket Azure devops any of those Central remotes we're going to talk a little bit about biases and threat model because that really changes how we think through these questions uh who what when where why so uh we're going to go to journalism school today and then talk a little bit about what we can do about this and and really why this is is even important to begin with so I have some biases I have been working with Git for a very very long time uh G is hard I feel like it's better than literally anything else and maybe a lot of that is inertia and maybe

a lot of that's just because it's genuinely great and most developers in my experience do not interact with Git from the command line and you shouldn't have to you shouldn't have to memorize a couple of shell commands just to to make some changes to code another bias I have is identity and authorization is really really really hard there's a reason that you can spend an entire career in just identity management or just authorization or authentication um it's because it's it's complicated and difficult and my last kind of maybe spicy take here is that Auditors are humans too we're spending a little bit of time here at the intersection of several multi-billion dollar Industries identity and

authorization endpoint management AG Regulatory Compliance developer tooling all tons and tons and tons of complexity here so that's where we're at um lastly for for threat model assumptions I am not going to talk a lot about State actors um when you have a an adversary with infinite number of time and money and manpowersupply.est

hey no bad code goes in and no good code leaves but we're not really going to talk about intellectual property law or malware detection or any of that we're really going to focus on but can you prove it so with that let's talk about that magical directory. git so when you clone a repository or initialize a repository a directory gets created in that project called dogit what goes on in here uh distributed is here to stay so this is the key point that we're going to have a hard time with Git and really really love about git before a distributed Version Control System um I started my career spending way too much time unlocking files in a

system called visual Source safe so I uh I have a sticker says social coding on here because antisocial coding did exist and that was when your team lead took a vacation and didn't unlock his files beforehand this easy conflict resolution gave us all sorts of really cool stuff but on an audit perspective it adds some some difficult conversations everyone has their own copy of everything locally on their end points and where they work and propose those changes are on their end points and there's always that one person in an audit who is like no no no my users took cyber security training they would never click a fishing email they would never do anything silly it it

does happen um but keep in mind that all of this audit is about a user on an endpoint so they are responsible for who they say they are they're responsible for all of the content configuration so storing binaries adding Secrets ignoring files all that happens where that code is actually getting changed and local execution of code so you have a a concept in git called hooks where at certain points in a developer life cycle so you pre-commit or post push these scripts can run and that can also add a little bit more complexity and then our endpoint you can sign commits that we're adding cryptography in those signatures on changes again one more endpoint control so this dogit directory is full

of magic and I put some Stars next to what most Auditors I've interacted with are going to highlight and that's the config file the hooks directory and the logs directory and I'm going to say rightly or not because some of these things don't really tell you what you really want to know because the first thing to understand about git is that the order of resolution of these configurations is friendly to local and hard to audit so local configurations are take precedence over global configurations take precedent over system configurations so that's great that you have all of your windows endpoints and whatever secm is called These Days however um that systemwide configuration can then be overridden by a developer's

local profile or be overridden Again by a particular project so if I'm working on one project I can have setting specifically to that so setting anything at get config is really just a suggestion it's not a mandate additionally none of these files are version controlled by your

repository what is really handy though is that at least locally on that endpoint you can pretty easily tell where what scope is setting each setting so if you use get config and you show that scope and you show that list you can see hey this is set globally this is set locally this is set by a system so at least you understand where those Scopes are set and Everyone likes to talk about this logs directory because clearly when you're going through an audit you see logs and you're like oh hey logs that's what we need but it's not logs in the sense of this is going to prove that Natalie changed this code it's logs in the sense

of these are the commits that have happened and what order they play in so highlighted a couple things here that are a little important your local state um each branch has their own folder here as well and then if you have multiple remotes each of those can be tracked separately as well so again these logs are a little disappointing we have a sha for the parent so that's the change that we're coming from we have our current commit Shaw we have who reportedly when uh reportedly as as detected on the endpoint and we have the commit message which hopefully gives us what happened but again none of that tells us what changed in that log

so having resigned to the fate of working for these answers now we need to figure out who even wrote this code this is the money slide right here um and that is the most difficult conversation that I have had with people moving to get with projects moving to git with trying to audit code in git is that there's almost always two identities and they are not reliably linked or how you want to link those two identities is up to you I think it's a better way to put that so there's who you say you are and there's also who you say you are to that get remote so get thinks you are who you say

you are it cannot create a commit without a name and an email address to use and this little bit of friction is so well known that the platforms for remote repo hosting in this case I think this is gitlab um will prompt you upfront if you click the button that says create a new repository this is how you set your name and this is how you set your email all of them do this because you can't even create a a commit without this without setting this info but who do you say you are as an example on this laptop my global settings are my work identity this is my work issued laptop and all of my work identity my

email my uh key signing all of that is set up for committing to chain guard's intellectual property however I also am a human being I code for fun I have my own open source contributions and locally not globally I will set up those projects to use my personal email and my personal SSH key for commit signing and those commands all they do is edit a text file they edit that git config file in whatever scope that we set up earlier and you can also edit it with them emac said open it in vs code like no one cares it's it's just a text file as an example uh I going to look at this uh this lovely

screenshot here so I just added some Wares and I did all the the fun things here where I said hey I'm just a maintainer I misspelled Gmail um all all of the things that should set up red flags all I did was like add whites space to a a text file but I can then go back and say hey this uh this commit was attributed to uh maintainer at the misspelled Gmail domain and if I go through get log and say hey show me all the commits with this this author I can see that uh allegedly again at this time I added some Wares at June

10th so I pushed that code and I think in this case this is GitHub and it shows up as verified remember how we said that there were two boxes of identity one on get and another on your remote in this case you can see maintainer is listed as the author of The commit but some Natalie pushed to this remote with credentials belonging to that account and more importantly that that code was signed by some Natalie's signature so who is responsible for this code does it matter that you are who you say you are when you control that identity elsewhere so somewhere between distributed is in centralized is where a lot of companies end up and one of these

models is much much easier to audit in some ways than another so how do we bridge that Gap because G is both distributed and bring your own identity but all of these audit controls are really around centralized account management centralized identity centralized cryptography so we have an identity provider that is interacting with that remote with s uh skim or samel normally and that is you kind of your your well-respected boundary and then what's happening on the end point I don't want to say is the wild wild west but it can be the Wild Wild West because now we need to prove it so what we can do now say we know that this account committed these

changes so even if they didn't author it they did push it to this remote and that her self-supplied key signed this commit so the key that I generated or somebody generated has been added to this account so it's a second Factor but it's not necessarily a second factor that to go back a slide comes comes from your identity provider again it's a user adding that key to their account in the remote so even if they were authored by someone else I would you normally argue that hey this account is either compromised and we have a problem elsewhere or that this account is responsible for pushing this code so in minimizing the ways that it can go wrong um I will never not preach

the gospel of scan um so the ability for your identity provider to provision accounts in I I would say child services so your your identity provider would be your central point of Authority for your email for your VPN for your endpoint provisioning but also for things like your account you know your chat for slack your chat for GitHub or your code for GitHub Etc um and if you can't do that single sign on uh yeah is there a question uh yeah system for cross domain identity management so it is a protocol that came out in oh goodness I'm GNA mess this up because it's recorded of course but it came out a couple years ago

2016 2018 somewhere around that time frame um and it's been very very popular in Enterprise software specifically for this use case so the idea is that when a new user joins your company or rolls onto your contract that you add Bob to a group and because Bob is now a developer on this project he'll get access to these files in SharePoint he'll get access to these four entitlements in Google or in these you know canva slack GitHub whatever whatever your your Enterprise stack is but it provides the ability then when Bob rolls off that all of those accounts belong to you and you can deprovision them so you can lock them out they're the account belongs to

you and you can automate that life cycle management a lot easier so it's an open standard failing that single sign on again gives you that single point of control of hey if we need to to sign into OCTA in order to access whatever like that will still provide you that ability to say hey when when this person rolls off their account might still be theirs however ever they can no longer access these resources um I will it is 2024 I can't believe I'm still having this conversation but I am please reduce the use of long-lived credentials anywhere they're ever stored in plain text uh this is passwords this is API tokens but this is also SSH private keys

so again we're talking about a lot of that intersection with endpoint management which is its own multi-billion dollar industry and then requiring signed commits doesn't do what you think it does um about half the time I have this conversation oh we have we we require all all of our developers to sign commits and that clearly always and completely airtight proves that Natalie wrote this code as as we'll start to see it really doesn't do what you think it does so let's talk about that a little bit so there's three common methods of commit signing gpg s mime and SSH so SSH was a recent addition so SSH Keys all reasonably familiar it's public private key pair that private key according to

your SSH D you know Damon needs to be locked down on the file system a little bit but that's still a plain text private key on an endpoint um you can store it on a a you know yub key like mine or if I I was about to touch it and then realized if I touched the Ubbi key it would blow up um the the text that that's how how ingrained oh yubik key let me just touch yeah I I'm well trained so you can you can store those those private Keys elsewhere and you should um CAC is a common access card so if you've ever been issued a identity card with a little PIV chip on it and

that chip hosts a a certificate you can you can store keys on there as well normally that's gpg keys and Es mime is the cryptography system most commonly used for email and genuinely nothing else I have not personally run into esime commit signing at all but think of it more as a tamper resistant seal on a specific set of changes not a link to Identity and there's some problems with this so every end user on every endpoint that's committing code needs to configure commit signing so when you sign a commit you're you're using the Das capital S every single time you commit this is a little bit of a problem sometimes you also need to normally

self-host your git server for custom certificate authorities so if you're using a SAS product it's typically unreasonable to ask gitlab or GitHub or bitbucket.org

to have 8800 different people with way too many certificates to to manage performance-wise so again you're going to need to self-host your commit or your git server for custom Casa uh you need to verify commits so having a signature is no good if you can't verify the validity of that signature and it's not possible in some platforms to reject unsigned or untrusted commits so again conditions apply because every platform and every version of that platform has their own rules and conditions around that um um but most importantly secure random key generation is really hard and it's really really really hard at scale so again we're adding more and more complexity to this system and note again that each

regulatory kind of compliance box has controls around aspects of key life cycle what Cipher strength are you using what Randomness are you using what algorithms are you using so this is is adding more and more and more for you to prove and again these all rely on Long lived private Keys uh the last thing I'll kind of mention here is are you really are are you who you say you are so in this case I I clicked the little unverified pill box and it says hey you need to to verify your email address to verify the signature and verified just means that the particular key used to sign that commit is also part of you know that

that user account's email address so it's trying to link that who in git to that who in that repositories that remote repository so making sure that in this case sumn Nataly github.com is actually owned by su Natalie it's not actually a part of git um but it is a very very handy feature on specifically public remotes because here's what that means it means that that one single human or organization controls both that email and the account so if somebody tried to send me an email to my my github.com account um it would bounce that I I don't work there anymore however I still have that email on my account adding those old emails back as

unverified means that I retain that commit history for all of the commits to that that email but more importantly also prevents name squatting on those old email

addresses and oh one more point is it only verifies that the key that signed that commit was verified or not at the particular time so I genuinely did work at GitHub when those commits were made and if I had taken the screenshot during that time those would all be a straight line of green verified so again this is where Time and Time matters here and then there was a very very common supply chain attack lately around dependabot PRS because you are who you say you are some malicious actors said they were dependabot and opened you know commits and and poll requests that looked like dependabot but were not signed um if you click that little green

button it will always always always be signed by a signature that is owned and operated by github.com so disappointed in our shifting identity we now need to figure out what even changed so in this case uh what changed is what files actually changed and I'm a huge believer in using for what they're meant for because that makes our audits a lot simpler tracking what changed is exactly what git does and it does this phenomenally well so I've made some assumptions here that we're all familiar with the basics of you know committing a a set of changes in git so we can spend an hour just talking about like this is what git is this is what it does but we're we don't

have that type of time but let's talk about making some of the harder questions I've come across a little easier so there's some 50 tricks some hidden foot guns and one extremely shameful use of said first is diffs and patches so you can use git without any Central remote repository at all git existed before there was a gitlab a GitHub a bit bucket a Azure devops kind of sort of um so git is its own thing and there are a lot of of places that use what's called a patch-based workflow so git itself doesn't use is not developed on GitHub um the Linux kernel is another really good example of that and I believe postgres as well so they work by

emailing patches around and these patches and diffs are not the same but they do carry that that similar set of changes so we've been talking a lot about the beautiful goys that can be built on top of your uh set of changes however those aren't necessary to forget to work patches are diffs that carry that again very self-attested or easily manipulated metadata on top of the file so you can see that this is you know from that's that that parent you can see a completely meaningless date but you can see as apparently some Natalie at chainu guard. deev did do something on Tuesday April 23rd and made a fabulous commit message um and everything below what's shown

here is a regular diff but you can see if you were you know reviewing this code manually that you could say oh hey these are the files that changed we created some files we deleted some files and if you are interacting with get at the command line it's format patch to create it and am to apply it but a diff does exactly what you think so if you're familiar with any of those visual diffing tools this is the what goes in and out of those and it just gives you that plain text diff and in this case this is a new file and you can tell that in a couple of ways the first way you can tell that is the

parent commit is all zeros so all zeros means nothingness and um I added this commit was made from the web all all den and the nice thing about these is that these centralized platforms make interacting with these pretty easy so if you click on any commit in gitlab or GitHub you add diff or patch at the end of that URL and you will get a plain text formatted to your browser to your you know API client whatever you're ending up using of exactly that so you can build a ton of things on top of diffs and patches if if you need them um you can interact with them with curl or an API all that good

stuff and there's a ton of shell Wizardry that you can perform here as well so this is one of my favorites it is taking git log it is sorting it giving me only the unique uh entries and then giving me the top five changes so in this repository I know that these are the five files that change the most so if you're starting to try and figure out like hey what do I even need to pay extra close attention to or what would be an anomaly that's one more way to do that and everyone has some level of shell Wizardry that they have done on git log because here is that absolutely shameful use have

said about every other code audit I've gone through at some point someone says okay look this is fabulous I'm glad that you have this lovely web UI what I really want is is a spreadsheet of changes I need to know who signed un things and I don't have the time to go through and click the 10 different pages in GitHub to go back in time on the history of the commits so here is that shameful use it outputs the URL of that commit for easy viewing if you want to you know open that in in GitHub or gitlab but it gives you the commit ID the author the signature status and name of the signer um and just number of files

changed and number of lines changed which I feel deep shame that I had to do this for an audit um and but everyone has a hill they they'll die on and wanting a spreadsheet of changes of who changed what is not the hill I will die on however all of that data does exist in git log like all you're doing is piping git log through a bunch of uses of said the other foot gun I see quite frequently is the use of G lfs um there is a a general rule around get repos and that is that if you cannot diff it in plain text don't put it in your repository don't put finished binaries in your repository don't put

dlls in your repository in this case don't put a Photoshop file in your repo get is very very good at diffing text and get is actually really bad at handling large binary files um but again in practice I feel like no one really follows this so there's this really cool Edition called G lfs so it's a set of extensions on top of git and it uses pointers to point at that big file in the repo and this gets really really scary every time I talk about it with Auditors because they're like pointers pointers that means that we're not tracking what's actually changed we're just tracking a pointer that's terrifying and then I talked to team

leads and they're like but we have all of this stuff in our repo already we can't move it to another system and then there's that extra step of using G lfs that can be some friction on the developer side as well and it doesn't always have to be this way so G lfs is defined in an attributes file so you can Version Control that file in a repo to say hey everyone adding Photoshop files to this repo add add them using G lfs and then it uses a filter called clean and smudge to perform those interceptions so as you're trying to commit files it will go ahead and smudge them so that goes from the

staging directory to like hey I'm actually going to commit this file that's the curved arrow on this diagram and then the clean goes from working to staging so it's that straight vertical Arrow so it looks to you on your local endpoint that you are interacting with the real big file because you really are you brought down that big file however once you start to change it to start to think about putting it in a remote it's actually going to go to a separate file store and there will be a pointer to that and that means talking through this gets super duper gross because things I've really been asked I need to perform a full AV scan of this file I need to be

able to intercept files and quarantine them I need to be able to understand what changed on this particular file system and for the most part this can't happen quickly enough for the get remote to accept or reject that commit because there's a very I think it's 10 seconds short amount of time before the the that accept or reject decision has to be made and this can also Break self-hosted Stuff but more importantly these pointers are actually designed in a a way that makes auditing very very easy so here's an actual real text example of a pointer um I just shamelessly stole this from G lfs's documentation but it gives you the version of G lfs that's used it gives

you the object identifier so the shaum and the size which means that if the threat model here is I need to know if somebody has changed this large file system either on that remote that they have access to or on my endpoint um it is beyond mathematically unlikely that two objects will share a shot 256 sum so that's 1.16 time 10 the 77th power or many many many times more than there are grains of sand on earth or drops of water in the ocean so additionally they also have to share the same size the exact same size so having these untracked changes as a possibility is very very unlikely or you know the the easier

option here is you can just use something that was designed for binary storage like there there are entire Suites of products designed for storing your npm packages storing your containers storing your Photoshop files Etc um getting users to use lfs in my my experience has been far more of a problem than any security implementation and cve around G lfs tend to be around remote code execution or resource exhaustion which are not you know tracking or untracking changes lastly I am once again asking you to please For the Love of All that is good in this world stop putting secrets and repos I'm just a girl asking you stop doing this um because when we start talking about

secrets and repos the very next discussion that that that I have is well how do I fix this and there's a whole industry on detecting and and you know as we heard earlier you're figuring out what to do about that proactively um but I'm coming in more in a a reactive fashion so how do you remove a secret from a repository you can't because once that that se secret has been pushed to GitHub gitlab even if it's private you have lost control of that secret because now let's say if everyone in this room has access to the same repository I do not know where that code has gone from that remote and even if I do I don't know the second or third

places that that has gone once it's left the the the Central and now it's on somebody's endpoint what this means in in practice unfortunately is force pushing changes so you are rewriting history big giant ugly red audit flag and then you are Force pushing those that that revised history to your remote figuring oh hey well you know github's not complaining about a leaked secret there anymore so obviously we're done and no one has ever seen that secret it was never leaked it was never compromised um that's that's not what happens so what what happens is these what we call tipon migrations or that Force push of you know we removed and rewrote the history of that code base um it's also used to

remove large files from a repo so rather than saying don't ever Force push because I am going to tell you that I'm going to tell you please just own the fact that you screwed up you committed your AWS key you're going to rotate it and you're going to learn from this um that's not always what happens but living with Force pushes means a couple of things it means first be obvious and once you're obvious like make it even more obvious like hey this is a force push to do something see you know an external issue tracker for more details so you know if we had an incident say hey please see this service now incident or please see this you know

jira discussion whatever that system is for you be obvious and if it's removing large files from an for an lfs migration so if you have that large file it'll be committed multiple times at each change so you're rewriting quite a significant portion of History only do that one thing in that commit and then consider using a a file called get blame ignore revisions to quiet down get blam to a reasonable amount and what this means in practice is if if you're relying on the ability to use git blame to look and see hey Natalie changed this chunk of code in this file three months ago and then her team lead went ahead and changed this

other block of code two weeks ago um having these really really noisy commits where a thousand files were touched um gets to be kind of gross and then if you're using a central remote Block Force pushing universally so block it at the that you know Enterprise wide level scope and have those logs sent to your seam so that if you are doing this you have an incident response person in the loop who has the ability to unblock this which might Force number one there of having that incident you know reasonably well tracked and it's going to set off all sorts of alarms in your security event system to say hey natal unblocked Force pushes and there was a

force push to this repo at this time it's not to say that it's always always wrong to redo history but it's definitely going to make these conversations a lot harder and then I put two uh projects there for if you're self-hosting uh for trying to detect Force pushes as well but that's controlled again entirely on the remote so arm with some wisdom here of what's changed now we have to figure out when um whenn is really fun because all of that time is completely self-reported so I can use get commit and then add a flag there to say it is three weeks ago a year ago 10 years ago whatever time that I want to put in there because you

can just set it to whatever you want and this means your GitHub contribution graph isn't actually proof of anything um and it's also remarkably useful for randomly seating those honey tokens from earlier in the day backwards through time or at least they look like they're backwards in time random date distribution with meaningful commits makes it a lot less obvious that this is not really valuable and without any intervention commits default to now whenever now is on your endpoint and and uh I'm not going to make any joke about Network time drift but um it is a thing that we all live with and we're all very sad git log also has a since and until

date so if you need to scope searches within that repository that's been phenomenally helpful to me many many times over and again what files changed most often so using that date filter here you can get the most frequent within that that date window again tons and tons of products exist in the developer experience and statistics and Dora metrics type tool space but this data does exist in G so now that we have we understand and are enlightened by that meaninglessness of time let's figure out where couple things to understand there are two places that git can execute code first is locally or client side and then last secondly server side typically server side things are on self-hosted

infrastructure only um so you're not going to just be able to randomly execute arbitrary SCP scripts on github.com like they're that's not really a thing that anyone does um and on the client side there are tons of places so pre-commit or pre um pre push Etc that you can you can do things pre-commit is the most common and generally you're GNA you know find and replace text no windows type new lines you're going to lint things there and then on the pre-receive side you can detect Force pushes you can block commits containing specific regular Expressions uh leaking Secrets um you can block unsigned commits however again on that client side that's all endpoint controlled things so just keep that in mind when

you're going through an audit and trying to prove it for infrastructure as code I have one very very strong opinion and that is if you are using persistent infrastructure to meet any sort of control don't ever use get checkout branches are Pointers to commits and explaining this has caused more gray hair than I care to to realize um if you're doing this try to clone with a depth of one meaning you're only cloning one specific tag you're not getting the whole history of that so you can say hey I only brought down this specific set of code and there's a lot of ways to interact with Git remotes so there's a lot of credentials and and various

controls that these can can cause a problem with so ooth or or GitHub apps so these are designed to be bot or or integration type controls uh deploy Keys which you can give right permissions to personal access tokens or API tokens again user level uh controls SSH account Keys oh hey commit signing Keys service accounts um single session jit authentication I'm going to pick on GitHub token because that's the ecosystem I know the best but a lot of other things can can you know generate Secrets during this process and again the control that you're trying to map to you know for me is ac2 which is you know account management and account life cycles you're trying to understand all

of the different ways that this code code could be pushed or this code could be overwritten or this code could be pulled or interacted with in any way and that just starts to add up there's been a lot written about commits and commit Styles and pull request etiquette I'm not going to go there I am going to say please provide a reasonably relaxed convention for your team that provides some structure and some room to mess up and change over time um the big thing I I want to talk about is is poll requests or merge requests if you ever want to move platforms so if you want to move between say GitHub gitlab bit bucket Azure

devops like all of those things have kind of their own take on that idea and the data Fidelity between them can change um so a lot of those bigger decisions consider committing to your repository as an architecture decision record so write a quick summary of what you know why are we using no SQL or why are we using cfco or why are we using whatever other Tech what else was considered and why we went with it and uh lastly what can be done most folks settle on something that looks like this if you want to add a little crypto it looks like this so you add a key server and you're having a second factor for that

endpoint but uh oidc is really really promising I'm going to say it's magic crypto it's not um it is a an open identity connection so it is you are who you say you are it provides a central Identity On A short-lived uh credential but what if we could sign stuff with it too and that's what Sig store does it adds a certificate Authority and it adds a transparency log for verification and all of the like Supply chains uh announcements that have come out of GitHub and a couple other places early you know earlier this month and last month have all been built on sigstore and then there's one other thing you can do but like what if we

could sign our commits with it too so this is what it looks like at work um I accidentally goofed up and have a verified commit there but um I did sign with sigstore and unfortunately uh GitHub gitlab Etc don't quite know how to interact with that yet so it does show up as unverified but if I go to that recore transparency log it will say hey Natalie had that for this time and uh she signed that commit and we're good more importantly you don't have to show up to every single argument you're invited to and in an audit this is the most important part um there's 800 ways to meet a lot of these controls write things down decide where

to centralize or not and go from there and also send everything to your seam because that is what you need to be doing anyway and uh yeah audits are stressful your team is human your Auditors are human too it's all okay um I did not leave time for questions I sorry well minut and a minute and a half okay

questions I'll just out

okay uh that is a loaded question because I am not going to talk smack about subversion um it it it it it's uh there's a lot of reasons that you would choose one over the other and for me it's more about everyone else is on git so I'm going to not you know break that either um I will mention that the subversion Bridge or that compatibility between git and subversion is no longer uh supported by GitHub so um yep yep sorry all right [Applause]