Good time to start. Welcome back from the break. It's a great pleasure for me to introduce now the second speaker of today, Matthias Neepert. Matthias is from NEC Labs Europe. His research interests are in relational learning, learning on graphs, learning with graphical models. He's doing extremely interesting work in this domain. He did his PhD at Indiana University, Bloomington, then had post postdoctoral stays at the University of Monheim and the University of Washington, and then he joined NEC Labs Europe where he had a very steep career. After a few years, he's now the manager of the machine learning group. There's a stellar career. We are very happy to welcome him here today and to learn about these exciting topics. You remember in Fabian Teister's talk also this work on graph data and relational data was highlighted as one of the next challenges in the field. How come you're here? Matthias, it's great to have you. But before you start, I also want to mention that you are a co-founder of several open source digital humanities projects such as the Indiana philosophy ontology project and the linked humanities project. Also, I also want to give credit to these activities of yours. It's great to have you here. And we are now looking forward to your talk. Yeah, thanks a lot for inviting me. It's looking at the set of speakers. It's an amazing symposium. My impostor syndrome is going really strong today. So my talk will be about new relational learning and some biomedical applications. And as Carsten said, I'm the manager and also the chief scientist at NEC Laboratories Europe. NEC is a Japanese IT company with a lot of different areas of applications of use cases. So yeah, one of them being in the biomedical domain and specifically in drug development. Before I start, I also want to credit my collaborators, so the machine learning and biomedical AI groups at NEC labs and specifically also Alberto, Brandon, Caroline and Timo who have worked a lot on the types of projects that I'm going to present to you today. So the first question that I want to answer here or, you know, elaborate on is why does an IT company like NEC care about, you know, graph data and specifically the biomedical domain. So you can see four different types of graphs that we have specifically worked on in the past, you know, two to three years. So we work quite a bit with patient data. So NEC is a big software vendor for software for medical records in Japan specifically a chemical compounds of course can be represented as a graph. So we've worked quite a bit with biomedical knowledge graphs, where the notes of the graph are things like the drugs, proteins, and also diseases, and the way that they interact and they can be many different types of interactions. And then also specifically some project that I'm going to talk about today as well is a network of peptides. So in this particular case here in new antigens, where we want to learn something about new antigens that can tell us, you know, how likely will they elicit immune response in cancer patients. And so, as you can see now we have this, this, you know, natural way of representing biomedical or medical data as graphs. And now the big question is, you know, how can we apply machine learning methods to these graph structured data sets. Here I should also make a disclaimer, you know, my kind of my overview of graph based machine learning is quite narrow and biased. So, you know, machine learning for graphs has a long history and this is specifically also, you know, the history of kernels for graphs that has worked on a lot. So I just want to mention that my view here is quite biased on recent methods of using neural network based machine learning methods for graph structured data. So let's go through a couple of examples, right, of how we have used, you know, representation learning for graphs for different data sets in the biomedical domain. So for instance, in drug discovery right obviously chemical compounds as I said before can be represented as graphs. And the problem here is now taking a set of graphs or maybe a big database of chemical compounds and mapping these graphs into a vector representation so that you can downstream classify these these graphs or perform a, you know, solve regression problem over them. The second type of problems that we typically encounter is that we have, for instance, you know tabular data so you know patient medical records. Then we induce the graph representation on top of this. And then we apply graph neural networks to note representations again. And in this particular case we learn note representations only and perform the note classification. So for example here, we might be interested to predict, you know, things like discharge destination length of stay and in hospital mortality for the patients that are the nodes in this graph. And that's a very typical, you know, the typical target problems for patient outcome prediction that are quite important in the medical domain. Similarly to the previous example, we might also have, you know, certain biomedical entities in this particular case here peptides. So new antigens. And we have particular measurements about them. And we also now want to represent these peptides as a graph, and then learn vector representations for the peptides so that we can perform in this particular case here for instance, a ranking of epitopes, according to how likely they are to elicit an in a cancer patient. And then finally, you know, we might also be interested in learning representations for notes and edges. Right. So if we might have this mentioned this before biomedical knowledge graph, where we have drugs and proteins for instance and different types of And then we might be interested to predict missing links in this graph, right. And so one particular type of missing link could be, you know, our two drugs if you take them together, more likely to cause a severe side effect, which if you took these drugs individually actually wouldn't wouldn't show up. Right, so then here the the problem is now the problem of link prediction in graphs. And so, you know, this was just to give you an example of the different types of of prediction problems that you can address when you are given a graph. Of course what I haven't really told you is how to actually do this. So right well what have people done here in the past and in recent years. There was a large body of literature so the area of graph neural networks in machine learning is growing tremendously I would say there are probably hundreds of paper per month coming, per month coming out. And so I will try now to on a high level, kind of, you know, categorize and sort a bit. And then show these different approaches for you and then also show in two instances, how we have used, you know, graph based machine learning in a particular biomedical application. So the way that I like to start, you know, explaining graph based machine learning and specifically neural network based graph based machine learning is to start with the success story of convolutional networks for images The image can be looked at as a grid graph. And what the convolutional network does it, it kind of moves know a small local kernel typically like three times three pixels from left to right and top to bottom over this image, and then reads off that information and by now stacking more and less, it starts off with this kind of local very local representation of the image and then builds more and more global feature representations for the images and this works extremely well, right. So the nice thing about images I mentioned this before is that the image can be represented as a regular graph so a grid graph. So the big question now for arbitrary graphs is where notion of top, you know, top to bottom and left to right really doesn't exist is what are good local structures that we can use as a substitute for this, you know, square shaped grid that we are using in convolutional neural networks for images. And when you look at the literature you can kind of see three different types of local structure that's been used. One is triples. One is paths or random walks that are being extracted from the graph and then used as the local structure that on top of which we had learned more global feature representations. And then finally also, you know, k hop neighborhoods of notes, where we are aggregating information of the neighborhood of a note to recompute or update the vector representation of the note itself. So we're going into two of those, you know, areas and specifically also how we have used those, you know, types of graph based machine learning methods in in the biomedical domain. So this one here is, you know, this, the classical example of representing a knowledge graph actually as a three dimensional tensor, right.  And you have relationships between them so you can represent essentially a knowledge graph as a set of triples right subject relation object triples. And now the way that this can be represented and this goes goes back to you know result from 2011 is essentially as a as a three dimensional tensor where every element in the tensor is one, if that particular entity that particular triple is true. And so the typical approach in what's called, you know, tensor factorization based, you know, knowledge graph embedding methods, the way that this works is that you usually choose a representation or an encoding for the entities and relationships. And in this particular case of Rascal here which is the first method to have done this is that we choose vector representations for our entities, and we are choosing a matrix representation for the relation type. Then we are choosing a scoring function. And there are many now out there. The idea of a scoring function is that you essentially combining the vector representations of the entities and in this case the matrix representation of the relationship into a score. And then finally you choose a loss function that makes the scores of, you know, the triples that you know to be true to be higher than those triples that you don't know anything about, right. And then you train the model and what you're doing implicitly here is you factorizing now this three dimensional tensor that's that's representing in this case here by a medical knowledge graph, you know, into different parts. So if you're new if you want to do relation prediction, what you're doing is you're giving now, you know, this particular relation, this particular triple that you want to know if it's true or not to the scoring function and if the score intuitively if the score is high. It's more likely that the triple is true than if the score is low. Yeah, so what what's been happening in this, you know, area of work is that over the last, you know, 10 years, you know, people have proposed more and more different types of scoring functions essentially right so starting with Rascal in the beginning. Now there are many, many different more of these scoring functions, but the basic idea is always, we are combining vector representations of entities and relationships into a score, and we train now that score to be high for triples that we know to be true. Okay, so now can. So, so, given that we can now do link prediction in a knowledge graph, how can we actually use this now for instance in drug discovery. So for instance, which combination therapies may result in severe adverse events right or which proteins are strongly associated with a particular disease, or which entities in different biomedical databases are actually the same, right. So all of these questions can actually be answered using link prediction. And so the typical process that we are following typically in, you know, in our company is to first create the knowledge graph from from biomedical databases and other types of sources. This is something that is not to be underestimated as a problem right so a lot of people focus on the method development. So really important step is to get a really good and comprehensive and clean knowledge graph representation of your particular domain that you might be interested in. One of the things that we specifically also do is we have developed a method that can extract and incorporate rules. So in addition to this kind of factorization based method that I mentioned to you before, we also extract rules. So we might also enrich the knowledge graph with additional modalities, such as for instance sequence data or other types of data sets text. Then we train our graph machine learning model for the different data modalities and predict finally the missing relationships between the entities in the graph. And just to go through one example here so for instance if we want to build a knowledge graph to predict polypharmacy side effect. We can go to different biomedical databases, we are collecting, you know, information about, you know, the entities in this in this biomedical knowledge graph, and also the relationships between them. We enrich it with, you know, additional features, for instance, from the gene ontology, or from other types of biomedical sources. And then we apply our rule based method. So the idea is really that you can now given this large biomedical knowledge graphs you really apply a rule mining method. That tells you something or that that that results in particular rules that say something like, you know, if drug A and drug C both target a particular protein B. So for instance they both up regulate a particular protein, then A and C may have a side effect together, right. And these rules are now combined with the type of factorization based method that I mentioned to you before. And other types of modalities that might be associated with the notes in this graph into a joint, you know, machine learning model. The idea here is that for different types of modalities different types of feature types. You can choose different types of encoding functions for instance for molecules you might choose a graph neural network for you know that this might they might be associated with a drug node obviously right chemical compound of the drug. You might also have, you know, sequence data associated for instance with the proteins in the in the graph. And for each of those you choose an appropriate encoding function right and there are many out there right now to do the way that you can pick and choose. Then you aggregate essentially the information from these different modalities, you concatenate or you you average so some sort of aggregation mechanism.  And we did this and we are doing this in many different contexts or for instance we're doing this in, you know, as I mentioned before polypharmacy side effect prediction, where we, you know, interested in understanding which drugs if taken together might cause severe, severe side effects, and we show that our method does really well and outperforms other previous state of the art methods here. But we can also ask and I mentioned this before questions such as which of the proteins are actually strongly associated with a particular disease, right. We also can compare with, you know, existing more traditional network based, you know, machine learning methods, and we can show that we're really doing quite well here with respect to these, yeah, these prediction problems. The nice thing and this is something that I should mention here is also that I mentioned that we are extracting these rules right. And so, you know, one of the nice, you know, side effects of extracting these rules is that we can actually look at the model when it makes these predictions so when it for instance tell us it tells us you know this protein I think is really associated with the disease. It also provides rules that we can actually inspect and take a look at so this is something that we found quite important. And actually what we did is especially also for the for the polypharmacy problem is that we could look at the rules and we could actually find some in some cases in the literature. You know, evidence that the rule found something meaningful right so that for instance, a certain up regulation happened that that was not really explicitly modeled in the knowledge graph that was essentially predicted and then it could be verified in the literature that that was actually really correct, correct prediction so this kind of explainability component of using also in including rules in these matrix factorization methods is something that we found is quite important. Okay, so this was kind of the first part of. I know the first type of, you know, machine learning model that can be used and what we've been using it for. The second one is the class of machine learning models and for graphs that are based on on neighborhoods. So where we aggregate neighborhood information into a new vector representation of the of the note that we're looking at currently. The idea here is that, you know, they are, of course now a huge number of graph neural networks, but one large class of graph neural networks can be unified with what's called a message passing neural network. And here the idea is that what we do is we are computing note vector representation so the vector representations of notes recursively by aggregating neighborhood information. Again, one of the things that we would choose is we would say, we want our, you know, message passing neural network to have a particular depth k, for instance. And then what we do is at each step, we are looking at the particular note I and its vector representation, and we computed as first looking at the neighbors of the note I so all of the neighbors J. So here vector representations from the previous steps. Then we apply a learnable function H so these are the, this is the function that has learnable parameters here. We then aggregate the resulting vector representations of the neighboring notes. And this is a crucial step right because in a graph we might have for every note in the graph, you know, a different set or different number of neighbors, and the structure also might be completely different. So here we have to choose an aggregation that is equivariant or invariant to to for instance the number of neighbors. And then finally, this function G which is also learnable combines the vector representations of our node I in the previous steps k minus one with this newly aggregated representation of the neighborhood of the node I. And now all we need to do is we need to specify some labels for the notes for some of the notes in the graph, and then we can train the parameters of this graph neural network, and to end, and then make, and then predict the class labels for the notes where the class label is missing. And because this might be not 100% intuitive, you know just based on the formula here. I personally like kind of this insight that what essentially happens in a graph neural network is that for every note in the graph what happens is that the neighborhood is unrolled into a directed acyclic computation graph that can then be used in a deep learning framework type of way, right. So for instance if we are looking at a particular two layer graph neural network, and we now want to look at the computation graph that's constructed for the yellow note that you see on the left here. What is happening is that you first look at the, because it's a two layer graph neural network you're looking at all of the notes, you know that are two layers away. And those vectors representations are aggregated combined. And so now we have a new vector representations for the one hop neighbors of the yellow note. And then in the second step, we aggregate the, you know, one hop, the representations of the one hop neighbors into the new vector representations of our yellow note. And then in the hop here when we are training, we are applying a loss function and can then back propagate essentially through this computation graph. Right. So this is, I think a nice intuition of what's really happening in these in these graph neural networks. And so now what, you know what have we actually done, you know how have we used this particular class of graph neural networks. So one of the, and again I should mention here right that I'm a machine learning person. So, I'm not an expert in the in the biomedical domain that's why I'm, you know, working with other people who are experts here, but on a high level. What you do when you're trying to design cancer vaccines is that you're trying to understand which of the antigens in a cancer cell will elicit immune response, because then you could essentially through, for instance, you know, a vector based, you know, the immune elicitation you could essentially teach the immune system to then attack the cancer cells through this particular new antigen, right. So Neo here meaning that it's an antigen that is developed within a particular mutated cell. The idea is that when a new antigen undergoes the different processing steps from, you know, transcription to cell surface presentation and receptor binding that they are different stages and for each of these different stages. We might be able to collect features right that tell us something about this particular new antigen. I think exactly what what we do in our work so so we are collecting this type of information some of that information is publicly available in many different, you know, also biomedical databases, biomedical studies. In other cases we we we get it ourselves. And so now what we do is we are now looking at, you know, these epitopes so again epitopes here peptide and new antigen you can think of our, you know, one and the same thing in this context here. And so the idea now is that we are building now this, you know, graph representations of these new antigens these peptides, for which we have at least one piece of experimental evidence. And that's kind of the crucial point here right so it's it's very expensive in many cases and in many cases we only have very few data points for these these peptides. So, the nice thing about this graph representation I'll go a bit more into the into the details in a second here is that we don't need for every peptide to have all of this possible set of measurements. Right, so we might just have one measurement for instance for one particular peptide, and we can still include it in this in this data set. So this can be constructed between the peptides in in many different ways so one of the ways that we've tried is to use blossom 50 so kind of, you know, to apply some sort of sequence similarity measure between the peptides. And then again we have this you know what we like to call multimodal peptide graph, where we have the notes are the peptides the new antigens, and we do have for for for them at least one of these measurements right that I mentioned in the in the previous slide. Okay, and then we have a particular graph neural network that we really like to use which we call embedding propagation so this is something that you know we published, you know about about three years ago in Europe's, which is essentially kind of an unsupervised version of this kind of graph new message passing graph neural network that I explained in the previous slides. So, how do we use this now right for for predicting or for ranking, you know new antigens in, and according to what the likelihood is that they will actually elicit an immune response so we start with our input data again these are the, you know the graphs and the different types of measurements and you can think of it as whenever you see a you know this colorful circle there, it means that we have a measurement available. The cross means that there is data missing so this particular feature type is not available for this particular peptide. So we can induce similarity graph and affinity graph. We've also been working in recent years on actually including the graph learning in an end to end pipeline but in this particular case here we would again do it based on for instance sequence similarity. Excuse me and what we then do is essentially. Again, we look at a particular note right this is what happens when we're now training this graph neural network. We look at a particular note a particular peptide. And what we do which is a bit special in our approach is that we're actually learning a vector representation for the features that are available for the peptide. And we're learning a separate feature representation for the missing values. So what what is missing for this particular peptide. We then aggregate these two different feature representations and apply a contrastive loss. So the intuition here is that. So the peptide, we want its vector representation to be similar to the vector representation of the neighboring peptides, right. And so now we can run this message passing your network scheme. And by running this we essentially propagating now this information. And while we are propagating this information we are actually performing an imputation in embedding space. So, when we're finished learning. We're finished training this model. What we end up with is for each of those feature types that we might be interested in, we do actually have a vector representation, right. So before we had missing values there but now we do have for each of those feature types of vector representation. And what I should also mention here which is quite crucial is that we are still. Distinguish so we're not just you know lumping everything into one vector representation, we can still distinguish, you know, different types of vector representation corresponding to different types of features that we might have, you know, for the particular new antigen. We don't have any missing values anymore we have these embeddings these different types of embeddings. And now we can just, you know, again concatenate these embeddings and train a standard of the shelf, you know white box even if that works supervised model, and can use that to make predictions, right. For instance, how, you know how well the particular peptide might elicit an immune response. We, again, so this is kind of the, you know, the core idea here again we, we are running this this graph neural network we are exchanging messages, we are imputing the vector representations we're learning vector representations for these different feature types. And we are then in a second step, apply a supervised model. When we do this and so for instance if we use something like logistic regression as the supervised model. We can actually see which of those, you know, at least in terms of embeddings right which of those embeddings contributed the most to the logistic regression model making a particular prediction. And then we can kind of track that back to the particular feature type. And even to the particular neighbors that might have been especially responsible for, for this type of imputation if the data was missing. So, it provides a particular, you know, a way of interpreting also the behavior of this this imputation method and the way that then the classify actually works in the end. I should say that, you know, this is something and I'll mention this in a second that we have actually integrated in a larger bio informatics pipeline. And again, this was done by, you know, mostly by Brandon alone who has done the bulk of the work of actually putting all of these different pieces together and building this bio informatics, you know, software really. One of the things that that we then do is we want to, yeah, we want to essentially predict how likely a particular new antigen would produce an immune response. Right. And so this is a pretty heterogeneous data set I mentioned this before it's coming from different studies. And here what we do is we are comparing our embedding propagation framework to other methods such as for instance gradient booster trees, or convolutional neural networks which have been demonstrated to work well on similar problems. And we can show that for this type of prediction problem. So again, predicting or categorizing immuno gene density, that our approach, you know, works quite well and statistically significantly better than than other methods. And we also, you know, did this essentially so you can think of it in this pipeline what we do is you know we are collecting essentially additional data modalities so this is really expensive I mentioned this before. It includes things like whole exome sequencing and RNA sequencing, usually from blood samples or biopsy. And then after treatment we check, you know, what is the teaser response, right. And, and here. So I mentioned before you know that we're doing this as a as a ranking so why are we ranking peptides. Well the reason why we are ranking peptides is because what we what we then do with this ranking is we give it to a company who then, you know, creates, you know, viruses that then, you know, carry the information of this peptide and hopefully stimulate the immune response in the patient. And of course, you know, you don't want to include all possible epitopes that you can find right so you want to kind of narrow this down to a smaller number of epitopes. And so this is typically in the range of 2025. And so that's why it's a ranking right we want to kind of find those epitopes that are most likely to elicit reasonable immune response. We evaluated this with patient data. And what's nice is that we could also show that we, we can find additional epitopes that would actually be missing if we would just look at methods based on for instance binding predictions, right. Like net MHC or something. So this is something that we're, yeah, that we're currently working on. I should also mention and again I think this is, you know, maybe something that, yeah, that doesn't happen so much is that is not so this, you know, bioinformatics pipeline that, you know, we have this graph based machine in the core of it, that this was actually approved also by FDA and EMA and is currently used in in clinical trial so we're currently in phase one clinical trials. This was also, you know, published. And again, this is work I want to, you know, plug the name again of mostly of Brandon Malone who has put this pipeline together here. So, so this is kind of to show you that, you know, you know, graph based relational learning really can make a difference. I wanted to, to also mention that, you know, one of the areas where we apply this is in. Gene regulatory networks, you know, with gene expression data where you usually have, you know, high P small n kind of situations, and where you probably also want to group. You know, the essentially the genes into clusters before you apply machine learning method. And he also just something I wanted to mention this type of graph, this type of graph neural network approach that essentially exchanges these you know messages into the nodes and then kind of clusters implicitly the notes has has worked quite well. Alright, and then, you know, finally, I'm probably finishing a bit earlier today. So we, we also mentioned this before. So if the graph is is given right that that's great. But in many cases the graph isn't actually given. The graph might be noisy right or you you might use a particular if you know similarity measure to create an affinity graph but you're not 100% sure if that's actually the best graph that you can find right. And so one of the research projects that we are working on is to actually try to learn the graph structure at the same time that you learn the graph neural network. So, for instance, what you see on the slide here is you might have, you know, particular data set that whether the data points are situated on a manifold. And what typically happens is as I mentioned before you're constructing the graph, you are training then and so this is the first step right you start doing the graph on top of this using some similarity measure between the the input features. And then in the second step, you are, you know, applying a graph neural network or some other method to to perform node classification to compute essentially these these vector representations of the notes. And as I said so so one of the interesting things I think is to actually, you know, kind of incorporate both of these steps that are usually performed. So distinctly, so individually, to actually combine these two different steps into one step and I think that that's a really exciting area of research is, which also touches on you know the notion of discrete continuous learning is you know how can we actually do this so how can we induce and update and improve the structure of the graph how can we discover structure in unstructured data initially right. So training an end to end pipeline that then actually performs for instance, you know, through a graph neural network and not classifier classification problem. So I think this is something that. Yeah I think is a really good nice nice recent research area here. Okay yeah and so that's it from from my side. Let me know if you have any questions about this work. Thank you very much. Thank you Matias. This was very clear and very fascinating talk. Thank you very much for that. I'm sure there will be a lot of questions. So, would anyone like to start from the network, Giovanni please. Hi. Yes. So, first of all, thank you I found it really interesting. Very fascinating talk. The question that I have is actually related to the top left of the slide, because I was just thinking that his application of these embedding propagation would be quite amazing for patient data because often there's the case of missing data on some of the features that we could have, and so on. So, as my question in the applications for example as the patient network on the top left, we would want to extend that model to new data. How do we introduce new nodes into the graph and then use the previous setup to make new predictions. Yes, this is a this is a really good question. There's a question that comes up also a lot actually in the, you know, when we actually present this work to people who might be interested in using it, right. So, do you have to retrain the network over and over again, when you're actually adding new nodes to the graph, right so so this is in the in the machine learning community oftentimes. The terms that I use there is like the trend, trans productive learning, where you assume that, you know, the nodes are already part of the graph. So all the patients are already there right when you train your model. And the other one is where you train your model and then you're getting new notes, you know, new patients in this case, you know how do you update without retraining the entire model, right. So, and there are ways to do this, I should mention that this is something that we actually did evaluate also in our paper here with embedding propagation and why is embedding propagation, especially suitable here, because what you can do is when you add in your note is that you simply, you know, you're simply sending now so you when you add a new note you also know the connections to the other nodes right so that's the assumption. What you can do now is you can now just apply the aggregation function, right. Once so what you do is you apply the, you know, the, the, the essentially the learned the functions h and g that I mentioned before right so these these usually projection functions on the features of the new patient, right you get this vector representation, and then you simply choose and so instead of, you know, learning this vector representation you just take the aggregation of the, of the neighboring notes. So the back the aggregation of the vectors of the neighboring notes and use that as the feature representation of the new patient. Right. And this is something that be tested also empirically, and it turns out that this works extremely well.  And so this is for sure a shortcoming and some people are, you know, also thinking about how to do this, this kind of updating of the model in a more efficient way without retraining everything. Right, so maybe just retraining locally or. Yeah, it's a good question. Thank you. Thank you Giovanni. Thank you. Matthias, a folk address. Yes. Matthias, a very, very interesting talk. Great results. And knowledge clouds of course also intensely used in my team at Demons and the LMU. I think it's a very nice general representation for data. One question I had when you talked about the combination with rules. I'm not sure if I completely followed everything but I think there's a lot of recent work where people apply some type of rule learning in context of knowledge graph or triple prediction and getting quite good results. And, but, so my understanding is on my feeling is that they get like the designs are quite good first that's very important, but they get a lot of rules like not just one, maybe thousands or something. And then the combination of these rules gives you a very good performance. Yeah, can you comment on that and also the terms of interpretability of these rules. So, so the current status I would say is that actually, you know, rule, purely rule based methods are actually catching up at the moment so they have been a couple of recent publications, where, yeah, essentially just using rules so without even machine, I mean, without, you know, embedding anything or using fancy machine learning that they can actually for some of the knowledge graphs do extremely well this that's what you already mentioned right. And typically what these methods do is they choose. So they also have an internal ranking of the rules right so usually and this is something that you can also see here. So this is the usually these rules are probabilistic in nature right so they say something like in 90% of the cases, if the body of the rule was true so the left side here of the rule was true, then also the right side was true right. And now you can essentially internally rank you know how, how confident we are that particular rules are true. And then you can kind of start by just applying the rules that you're extremely confident in. Right and this is essentially what these methods do so this is their way of dealing with a lot of rules is they kind of internally rank them, and then only apply the top rules the top top rank rules, right. So this is one side so they're catching up I think on the other hand, you still do have knowledge graphs and this is also what we observe where embedding based methods. So the type of tensor factorization methods right that that, you know, also is coming out of your lab. And that they, they still outperform rule based methods, right. And so our stance here is that we should try to combine the two, right. And one, one, and they are now a couple of proposals here and one way to do this is to really simply. We use a probabilistic model like for instance, what we use is a product of experts.  So the rules tell us you know we believe that this triple here should be scored really highly. And we get a score from the embedding method. And then we just combine these two probabilistically. Right, we just say, Well, you know, if, if, if both of them give us a high score then you know the overall score should be higher. And that's something that works extremely well and is also interpretable right so you can actually then look and see okay, these rules actually contributed to to the prediction of the method. So you can select some of these ones, let's say 1000 rules and say for this particular prediction only these five or so. Yes, exactly. It's specialized for a particular prediction, right so you get these two rules where the ones that are really important for that particular prediction. Thank you. Hi, so thank you very much for the talk. So when you were presenting the context at the very beginning, the first application that you showed was the classification of entire networks so where many networks are are the impute and then you want to classify the networks entirely. Do you elaborate a little bit on methods to do that so for example, are they mostly supervised or unsupervised or do you know some names of such methods. Yes, so, so let me actually go go back to the slide just to provide a bit more visual visual context. So, this one here. Yeah, so again the yeah so the question is you know what what because I just I didn't cover this really in my talk. What do you do if you want to actually learn representations for entire graphs like for instance chemical compounds right. So one way to do this and this is based essentially on on the graph neural network presentation that I had in my talk is that you learn vector representations of the notes in the graph first, so to speak right, and then you globally aggregate the vector representations of the vector representation for the entire graph. Right. So so and you can do this also end to end so for instance right. Let's say you apply what I explained in my talk right this this kind of message passing graph neural network. What it ends up doing is it's computing vector representations for the notes of the graph right, and then instead of stopping there. You say well now I take the sum or the average of these vector representations, right, which then gives me one vector representation for the entire graph. And then I apply some loss function for instance if I want to classify graphs right, I apply a loss function that says you know this molecule is toxic or whatever, and this one isn't right. And this is the most kind of let's say naive way of how you could use standard graph neural networks that typically compute note representations, also for for graph classification. But this is just one way which builds on what I presented in my talk right there are other ways to do this for instance graph kernels are, you know, one prominent example where, and in my opinion, still, you know, not at all outperformed I think by by by graph neural networks is this is a very controversial topic because oftentimes also you know these benchmarks are not very meaningful I think sometimes that that are being used. So I think you know graph kernels is another good choice. And then we've also worked on a couple of other methods and of course, like always in machine learning. So one example that I gave you of kind of averaging the vector representations of a graph neural network. Now more sophisticated ways of aggregating information right from the note representations into a graph representation have also been proposed, like for instance a form of differentiable clustering, right, where you kind of hierarchically cluster more and more and then end up with one vector representation. So this is what's called diff pool. So there are many different ways of doing this. And I think the first that what I would try is graph kernels or a graph neural network with some simple aggregation function on the on the note vectors. Okay, I will think about it. Thank you. Yes, so there's one question on Slido and then Rima from the from the network in this order. So Stefan on Slido asked what if not a node is added to the data but a new feature dimension modality is there an easy way to extend the graph without having to rebuild it. Yeah, also also a very good question and I think here the answer is at the moment know if you because what you know what what a graph neural network really does it learns a mapping from the the feature space so associated with the nodes right from the feature space to this embedding, right. And if you don't have a particular feature at all part of the training. Then it's, it's, it's not possible to just add this after the fact. So I think that is something that where you so if you add new feature so completely new feature types right not not just that for one note you suddenly get a new value or something that's possible but if you add a completely new feature type that you didn't have before, then I think you really have to retrain. Thank you for that. Now Rima is next. The question from inside the network. Hello. Thank you Matias for the nice talk. That was really amazing. So, I'm actually working also on problems applied to clinical data, however, and have one question concerning the way you chose to represent the vector representations. So you mentioned you have one vector representation for the available data and another for the missing right. So, I was wondering, have you tried one architecture with only the available data vector representation and if you did what is the performance you got. And the second question is, how is it different of the vector representation of the available data from the missing data in your case. Yeah, so the first question is, you know, did you compare. So by by, you know, I mentioned in my talk that you know what we do is we kind of distinguish. We separately learn a vector representation for the available data for each note right and for the missing data. And the question was, so if you don't do this right. So if you just pretend, you know, then you know, there is everything is there or you know you just use some sort of standard value for for missing stuff. Did you compare and the answer is yes we did compare we also compared actually to standard imputation methods right so there is of course also you know standard ways to impute missing data. And we did compare certain statistics for instance of the of the features that are actually available so the values that are actually available. And we did compare to to these, you know, to these other methods, and this worked significantly better. So so kind of separating essentially the, yeah, the missing and the available features worked really well. And so how does this, how does this look like right so so this is a bit of a difficult question to answer. But I would say what what really happens is that you, because you're doing this contrastive loss right between every note and the neighboring notes. What happens is that you are kind of, you know, propagating information from the neighboring notes and their missing data, and also the data that's available into this missing feature representation. So essentially what you're doing is your, your kind of have a flow of information from the neighboring notes into this vector representation of the missing data. And that's really I think what what what makes the difference but it's an intuition that I have right. It's not something really quantitative that I can, that I can give you here. Does it make sense or. All right, yeah. Thank you. Thank you. Now, I would have a few questions but yes. We have done a lot of research on graph kernels as you mentioned, and there are some related concepts between these two fields and we made some empirical observations in graph about limitations of graph mining and I wanted to ask you whether you whether you experienced the same in in graph convolutional networks. So one thing is the vice filaments also use this neighborhood aggregation scheme and what we observed in practice is that the depth of that scheme like how often you repeat the aggregation how deep you go when unrolling the graph as you as you called it that this depth is not very deep. It's usually in the in applications. I haven't really seen examples where you have to go beyond level three often level one level two is already sufficient to get the best predictive performance. So my first question is, have you seen examples where you may one should go much deeper. That is a very good question because similar to what you mentioned about graph kernels also in in graph neural networks and graph convolutional networks specifically. Usually the best choice is to have depth to so so when you do this aggregation step that I mentioned this unrolling right, you only go up to the two hop neighborhood of of each note, right. This typically works the best people have tried to go to 345 and usually that that doesn't work well so you see how your performance actually degrades right. And I think, but but but there is recent work who tries to kind of look at this more from again from a methodological point of view so is it maybe that we need, for instance residual connections right. It's like what people have done in deep neural networks for images right like these these residual shortcut connections should be also maybe try to use those in in graph neural networks right because maybe there is some sort of vanishing gradient issue whatever going on right. And so there is a lot of work in this area. I personally. My point of view is that it really depends a lot on the type of graph. Right. And typically what we see in. So this is kind of the irony right so the typical benchmark data sets that people use in graph for graph neural networks which are the citation networks Cora and sites here right. They typically have this what's called the smoothness assumption right so that you know things that should be classified in similar ways are actually close to each other in the graph. So if if you actually apply then a graph neural network what's happening is this is, you're kind of making the vector embeddings of things that are close to each other in the graph similar, right. And then because of this assumption or this property of the graphs that things that are the same, have the same label in the end are close in the graph, you are doing really well right even if you're just using depth two or one. And so I think what is really missing is to find really good. So it's really a bit of a data issue, I think a benchmarking issue is that I'm pretty sure there are graphs where you know distance is not necessarily distance in the graph is not necessarily indicative of same label, right. Where you have for instance in, and I think this is actually something where the biomedical domain can also maybe contribute something where you might have, you know, big network and the labels are completely different in different parts of the network, right. And they are, even if two things are close to each other they might have a different label. Right. And I think this is kind of what's actually missing. And if that is something that, you know, we see more so different types of graphs really that have different properties. Then I think also going to further depth and having the ability to propagate from further apart, right over the graph, can actually be beneficial. I think it's a bit of a, I think really a, yeah, what type of graphs are really used for these benchmarks, right. Yes, I agree. I, I think these cases can exist just in their relative frequency compared to the other ones where neighborhood implies the same label is so much lower in the application that I'm aware of that it's not so, so easy to find them or to find them in large, in the application on this. Thank you very much so I agree with what you said. And another aspect you mentioned here on this slide 30 but also in your outlook on slide 37 this construction of the similarity graph. So I've also looked at a lot of applications of this in bound mathematics and very often and I came to very similar observations as you did. And very often I asked myself and I also went experiments checking what if you skip the graph altogether if you just take your input data, and you compute a similarity matrix on it or a kernel matrix or whatever you want to call it. You're learning directly on that and the, and you, you get rid of the, of the intermediate step of defining a graph on it I have seen many examples where the intermediate graph is not really necessary you could just learn it on the full similarity matrix as well. So, in light of this I found it very interesting in your outlook that you, you make the same observation but come to a different conclusion maybe that one should learn the graph the intermediate graph end to end. So this is a really great question and it's actually something that you know it opens the door to a lot of related topics in kind of discrete continuous learning so the question for to me boils down to, why do you need to create a discrete and sparse structure to begin with right. Why not keep it dense and have even if it's tiny have all of the weights there right have it essentially be a dense fully connected graph so to speak right. And then just train this right then then we don't even have to worry about, you know, in using or finding the right graph structure right. So, there are a couple of possible re re bottles essentially to this right one is actually, and this is maybe a bit counter intuitive is actually efficiency. So when you actually introduce a sparse structure, and you use sparse matrix multiplication, you can actually compute this much much faster than if you have a dense matrix. So this is surprisingly one of the things right that if you, if you may actually learn sparsity then you are more efficient if you if you're leveraging the sparsity more meaningfully right. So this is one answer. The other answer and this is something that we actually answered in one of our papers is, in some cases, it does actually perform so the accuracy right is actually better if you actually learn dense, sorry, sparse representation. Right so that's the second one. And actually interestingly, we just discussed this in our group recently, they are now an increasing number of papers, also even in reinforcement learning in other areas, where actually the latent code is actually going to be discrete. And it's something about some sort of compression is happening right if you go to a discrete space that could be potentially superior than if then having just you know a continuous essentially space where you just have you know different types of larger and smaller weights. And the third one is actually and this is something that I find also quite, you know, makes sense to me is interpretability. So for instance I mentioned, you know, gene regulatory networks, right so you could treat, you know, the measurement the gene expression data as one big matrix, and you don't really care if there is a graph there right you just use it somehow downstream to solve a particular problem. Right, but if you actually then do this learning so if you induce a particular structure on top of the genes for instance in this case right, you might first of all be able to include domain knowledge that you might have. Right, so you might actually have particular inductive biases that you can induce there, and you can actually look at the resulting structures, and you can see okay yeah so here my algorithm decided that there should be an edge between these two genes for instance right and you can kind of take a look at it. And that's maybe a bit more interpretable than saying, yeah, my method assigned a weight of five, you know to this pair of genes, and a weight of zero dot one to this one, right. So, I think that there are several potential answers to this and, again, it goes back to like always in machine learning. In the end it boils down to what do you need in your application and what's the, what does the data look like and what works. But I agree with you it shouldn't be always the answer you should learn this or you should have a graph. Sometimes it also works perfectly fine to just not even care about the graph right to just treat it as a dense matrix essentially. Very good answer. Very good answer. And a very inspiring talk and introduction to this field. So, many thanks on behalf of the entire network and the YouTube audience for your presentation Matthias, it was a pleasure to have you here. Thanks a lot. Thanks a lot. It was, it was fun. And thanks for the invitation again. And we send a round of virtual applause to you.


Hey everybody, thanks for tuning in today to Clyde Smith's monthly webinar. Today's topic is on how do mature DevOps teams manage security. So before we get started, let's go through a few housekeeping notes. We have prizes to give out. So we have two free lunches and two free prize packs to give away at the end of the webinar. So be sure to watch till the end to win a chance to be in a chance to win. We're also streaming on Twitter, on LinkedIn, on YouTube, as well as our webinar platform. Please post questions to whatever platform you're using. The wonderful Hillary will be monitoring our channels and giving them back to me. We're going to be holding one or two polls. And again, you post in your platform or tweet or chat and we will be looking for those questions, your answers to your polls. So we have two really amazing guests today for our talk. So let's bring them on stage. Hey Nigel. Hey. Hey, so today we have Nigel Kirsten and Jack Chester Nigel Kirsten is the field CTO at Puppet by Perforce. And he's the author of puppets much love report on state of the DevOps. And we also have Jack Chester. He's the senior staff software developer at Shopify. He's an author of a book K native and action on building services applications. And he's the chair of open SF software repository working group and heavily involved in Ruby's open source community. So thanks for coming today. Hey, and Nigel so you have released 10. I think that's the full 10 reports every that's a lot on the state of the DevOps. So how was that? It's been a pretty massive effort over the years and I have to say, you know, I'm sort of the last person standing so to speak that the people who I if you're going to talk about the history of state DevOps has a bigger impact than, you know, so Alana Brown, who's since moved on and now works at remote.com. It was her idea in the first place and she was she really drove it for a number of years. I was co-author. And then when Dr. Nicole Forsgren came on for four years, I think it was there. She really bought it level of statistical rigor and research to the whole project. But there's been so many people Jean Kim, James Turnbull, jazz humble, Michael Stonkey. So many great authors over the years. But last year for us was a really big one because it was 10 years and suddenly made me realise how long I've been messing around this industry. I had to look up the term for this the other day of semantic satiation. You know, when you say a word over and over and over again and it stops, it loses all meaning. I think DevOps and DevSecOps are kind of like that. You say DevOps 20 times and it doesn't mean anything anymore. I'm trying to get to 10 years. And so what's once number 11 going to be out or are you still going to be as big a part to it? Yeah, I'm guiding it at the moment. We've got a fantastic researcher, Ronan Cleenan, who's taken on sort of the bulk of the work and is working with some research firms for us. We're trying to do something a bit different this year because I think I'm looking at about this. This topic goes forever. But basically, I think DevOps is now such a big field. It's very difficult in a single report to sort of come up with interesting, useful findings. You have the folks at the beginning of their journey, the folks who are very much post DevOps, the folks who've moved on, who've tried it, who it doesn't work, who it does work, and trying to do all of that in a single report. I think you just end up producing a book every year. So this year we're just focused on platform engineering. I can't write a book every single year. It gets to you. Absolutely. And Shaka, tell us about how you recently, I know you're focusing on open source security. And I'm a long time listener. I haven't gotten out of your working group software repositories. And I'm just wondering how you got into that and what was your journey to? Yeah, I've been co-chairing or deputy chairing. I don't know how you want to describe it. Dustin Ingram from PyPI from the Python Software Foundation. How did I get into it? I used to work for a company called Pivotal, which I really enjoyed my time there. And one of the things I worked on at Pivotal was what was called Pivotal Network. It was our distribution point for all our software products, which we needed to do legally. And some of the products got installed in cages and the Arm Guard because they were fairly sensitive sort of operations. Is this like an infimism or really? No, this is really a thing that happened. Like the software, like the USB stick would be walked under Arm Guard. Like it was that kind of a place. Okay. And I suddenly thought there are people in the world who would be very interested in getting inside those cages through our software. And that was one of those, oh, expletive moments. And that led to my interest. That was sort of like the lightning bolt that led me down the path to where I am today. Oh, cool. So our topic today is how do mature DevOps teams manage software security? So I thought my first question I'll pose to Nigel and like, I know we're saying DevOps means nothing anymore. But what does DevOps mean? Is it just automation and cloudy stuff? It's just tools, right? Yeah, I mean, this is, I think it's a tough one. And you talk to folks like Patrick Dubois, who was very much coined the term. And there was a deliberate, it was very deliberate that there wasn't a clear definition. Here is exactly the reductive definition we have of what we're trying to do here. Because in many ways, if we tried that, if you look back at the early days, it was basically a bunch of sys admins going, how do we actually be agile? How do we actually take agile in spirit and apply it to operations? Oh, look, we have all of these cultural problems, all of these accountability, you know, ownership doesn't match authority, all of these things. And I think we had had such a vibrant, interesting, exciting space emerge because it wasn't really tightly defined. And you turn up to DevOps days and you could get a talk about just about anything. But then we hit the enterprise. And I think the lack of a definition meant that, honestly, like shyster vendors stepped in and started going, we do DevOps. Here is DevOps in a box or consultants coming along in a similar way to agile and safe and various, you know, sort of permutations like that. But I don't think it particularly true to the original spirit. So as far as what it actually means to me, I take a pretty big tent approach. It's a loose collection of practices, technical and cultural, to get over organizational boundaries inside organizations so that we can ship software with less stress and better. And that sounds really vague and could apply to just about anything, but every time I try and narrow it down much more than that, I end up cutting out something that I think is important. Yeah, it was like I worked on those teams where it's like every six months, I think that was a normal kind of thing. You would release something and it would be very stressful and something would go wrong and then you'd have to roll back and it was a high stress moment in a big long journey. So I think that moving away from that is a good thing. You think that's having 183 people on a bridge call over the weekend? Yes, no one ever wants to do those calls. Yeah, so and so how does that, how do you see security? Is security becoming being brought into it more? It wasn't like at the start, we tried to merge development and operations. And now we're like not just now, but now we're like, oh, security are kind of still a bit siloed. Let's bring them back into this tent. And is that how you see it, Jack? Yes. And unfortunately, and just because of the sort of the economics of the situation, it's going to be siloed for a while in a lot of ways. There's just not that many cybersecurity folks to go around. So a lot of organizations either deliberately without thinking about it or out of regret, wind up with a central security team that acts as a gatekeeper, which we know from our DevOps days is an anti pattern. The other thing I see as an anti pattern is again very much like the experience that DevOps went through the evolution is the idea that there's a box of software you can install. And today you have security and that's not true at all. And it's, it's, it's a pity that we have to go through this evolution, but I'm, I'm hopeful that will come out the other side with something better. And I know it's not a box, but is there like some nice tools? Well, a bit of a lag up. Yeah, it is important to think carefully about your tooling. I think the similar rents who's the CEO of a company called chain guard says a lot and I agree with him I had a similar sort of model once upon a time which is that build is production. The systems where you are building the software as sensitive and you know risk dense as production itself because as I said, you know, like if somebody gets into the bucket of bits, you are in a world of hurt, and a lot of the time people historically have underrated that risk. And so the bucket of bits has been the fastest path into production to attack the build system itself or the the artifact system itself as well. So in terms of your software, you should think carefully about about those systems and securing them and hardening them and applying all the security practices you have now to them. But I think there's there's sort of like two great tributaries of risk or two great tributaries of security risk that you can think about flowing into into the river as it were. And one of them is that build system upstream dependency risks that come from the outside of the organization and then risks that come from the inside and the really big one is making sort of, you know, unintentional errors in your software that lead to a vulnerability. That one I think doesn't get as much time as it needs to because it's hard again to install something, or it's hard to have it, you know, a checklist that says I have now secured myself against security errors. Yeah, actually, one of the times where you probably as a developer have the most power over security is when you're bringing in these dependencies. What like what is it that you should consider when you're like considering bringing in a brand new dependency like water that you could like what is the checklist should you have a checklist or you can use or should you be able to test anything on your developer. Well, yes or no so that that's an emerging field right now is is people producing these checklists. There's even a startup called socket dot dev who have sort of automated the checklist for npm, at least.  Quickly to problems. You also want to look at security practices like do they have MFA enabled on the repository accounts that they use. But also you want to make sure little things like are you accidentally installing a different dependency from the one you thought are you making a typo so double check that you're getting the package you expect to get little things like those can add up to a lot. So I think we're in the early days of having having a strong story about how to pick dependencies with a security point of view. It's funny something you said there's our calendar jump on which because I think one of the things that's underpinning all of this is how hard it is could you know software development as a team sport the teams keep getting bigger and bigger with different roles. And it's often really hard as an individual practitioner to actually make a good decision with your locally or globally optimizing. And I think that's what a lot of this comes down to it's like your your job that you're being measured on is to ship some software and some features resolve some bugs or whatever. And if everyone just goes for the shortest possible path to get there you end up in a situation where the environment they're operating in becomes more fragile more error prone more insecure. And yet we're just not very good as human beings working in large groups. How do you surface the right kinds of things to make a decision between local and global optimization. I don't have a solution here. No, if you have a solution then I urge you to put your name in for a Nobel Prize in economics. Exactly. Because that would be a pretty big breakthrough. There are many points in the software lifecycle like the source code, the CICD system, the artifact repository, the dependencies the external dependencies on public repos. And then all the tooling is as well, you're like, you're scripting your environmental variables like it's just, there's just a lot. There is there is and that's that's one of the hard things about being a software developer is that there's so much to know about so many topics that it's hard to be an expert in everything. I, again, I wish I wish I had the solution where I could just, you know, do a sort of an Isaac Asimov thing and you play a tape and that puts a memory in your head. You can tell how dated that story is. Yeah, exactly. You put in the real to real and some blinking lights and there you go. But I think there's there's still a lot of value in creating a minimal level of awareness of the possible issues you don't have to necessarily know the solutions. You just have to know a that there might be a problem here and be where you can get help. Really, and I know both of you are are I've talked about how cultural change and how people are actually and focusing on people is is a great way to get better security. Do you want to talk about cultural change in DevOps and how to how to get your DevOps processes. Really nice and secure using culture. So I think there's a bunch of things to I think unpack there one is that DevOps and in a lot of the most significant tech movements we've had of how we build software. These are grassroots movements these went by people at the top of the hierarchical pyramid inside organizations these are people who are down at the bottom. And so it's easy to sort of go. We have a cultural problem. And one of the things we found out from last year's state level support when we did a bunch of qualitative and quantitative research was that all organizations with lots of what we would call cultural problems talk about culture all the time. But organizations that don't have many of those sorts of problems. They stopped using the word culture because it's not it's not actionable. And it's actually encourages a weird kind of form of helplessness inside organizations like if you're an individual developing you like up. Well our culture doesn't allow for people to just make those sort of decisions everyone goes. You know it's like an earthquake when you're going to do about it you know you just sort of wait for it to move on. But organizations that actually implemented these sort of changes and had fewer cultural problems. Somewhat paradoxically don't talk about culture they talk about specific things. We have a problem with ownership we have a problem with making decisions quickly. We're the problem with documenting tribal knowledge or ancestral knowledge around a code base. Like all of these things are quite actionable. And one of the things I found really interesting last year with the team topologies authors Manuel and Matt. If you haven't read team topologies it's one of the best organizational design books ever around tech. And their big definition they came down to was stop talking about culture. Talk about what you need to do to be able to ship software quickly with low cognitive load and stress on individuals. If you actually look at those things and identify them. Then they start becoming things people feel like they can do something about. So that was a really long winded way of saying culture is massively important. But you've got to go at least one level below and go what is it we're trying to actually achieve here. Let's not just say culture and throw up our hands. But let's go what's the problem and how are we going to fix it. And then you can make like incremental changes and get better and better and better until you've just. And people can tell if they're making a difference. As you say when they're working currently one of the things I found really frustrating when I worked at Google was there was this ineffable phrase. Googliness of people go well that's not very googly. And you're like I don't actually know exactly what you mean. And I'm pretty sure you're just using this as a weapon to get you across. We need to get that the Googleometer. Exactly. And so on that you guys think that metrics are important to improve software security. Is it like part of improving your DevOps like. I would say it's like metrics.  No, no. But to answer the question is, as I see it, metrics are essential. They're not enough. And as we all know, if you govern purely by the metrics two things happen one anything that's not in the metrics you will ignore. And to if what you're doing is like a control loop where you have a little controller. You think of yourself as a little controller you've got your sensors which are the metrics coming in and then you've got the actuator which is you doing stuff to the system. It turns out that if you want to improve the difference between the target and what's actually happening now. The easiest thing to do is to fiddle with the sensor. Right, it is much easier to gain the metrics than to actually improve the system. So you need to be aware of that and the reason that that's important is that if you tie punishment and reward to metrics, they will be immediately gained within each of their life. So those would be the two cautions I'd give about metrics. Yeah, that's very human to like change the change the measuring system. It's a really good example of this where they try to incentivize all of the tellers to getting everyone to open up bank accounts. And instead what they end up finding out was that all of these terrors tellers on mass, we're doing the sort of natural optimization there which is just going okay let's open up lots and lots of accounts with people whether it was a good idea or not. Yeah. Oh yeah, I remember when I was in, I was in Curry's it's like electronic store and I was a cashier. And I had to really get my metrics up on selling insurance I think on product, but I didn't see what the product was and I was like this is my this customer is getting my two cents. Would you like insurance on your product and she just looked at me and goes like no. It was a vacuum cleaner bag. Yes. Very good. I know I asked a question. Yeah, I would say use use metrics to sense the environment. But as I said beware time punishment reward like if it didn't work for the Soviet Union who had unlimited authority to try to make it work and unlimited supply of men and women with guns and dogs to try and make a metrics governing system work. Then it's not going to work for you. Right so use with caution. Yeah, I think there's a good example so to cut you off here is like because I get asked this a lot about the big four metrics that came out of the work we did with the door folks and that they ran with you know the meantime to recovery change failure rate etc etc deployment frequency. And it is horrifying what people out there in the world have done with these metrics they were a same collection of four metrics that pull in different directions so you can optimize one too much at the cost of the other. But you literally get teams inside enterprises competing on how to improve all of these things and you know exactly as I was saying like you can improve deployment frequency. And mean fake change failure rate by deploying more often and not being as good at measuring it for looking for errors. And so you get these teams optimizing for 1% 2% 3% improvements in these metrics and sort of losing sight of the biggest picture. But to I guess bring this back to a security lens. The thing I often talk to folks when they're trying to do DevSecOps inside organizations at the start of this journey is like how quickly can you push a change to production and know that it's actually gone out. Because if you can't do that quickly if you can't respond to something push out a fix to it or a change of any kind and know whether it worked or not. That is just the 101 sort of substrate and you can spend all this time optimizing all sorts of other policies and processes but if you can't create change in your environment quickly and reliably and be able to see the results of that change. Like stop caring about DevSecOps and all these things just fix all those things first. Yeah the worst time to find out that you can't deploy to production quickly and safely is in the middle of a security incident or an outage. Absolutely. We both found out that recently with Log4Shell. And on Log4Shell is like, do you see critical vulnerabilities and updating your software, all the dependencies as in having a process for that being really important or what you, yeah. So actually on that we have a poll. So the question is do you pin your bills or do you update to the latest. So this is sort of this question comes up with it's mostly around vulnerabilities. Well there's loads of good reasons to update but with respect to security. So if you update to latest you'll get all the fixes but if you pin your bills you're not going to be tricked into updating to a bad version. So and so we see here there's most, it's kind of half and half but most people prefer to update to the latest. So 24 said by 49% update to latest 20, 40% say pin my bills and the rest are it's not important to me. So I think and I don't really feel like this question is solved. So in Claysmith we always say, we recommend to pin your bills, but like, if there's a critical vulnerability it'd be great if you're updated as quickly as possible so I totally see the other side. So we like to say pin your bills but then use Tulane like dependable or I think renovate or to give you a prompt and alert appeal or to with an update to the latest and that will kind of quicken that cycle. So what do you guys think on that topic. That's a bit of a horn is this I'll let Jack answer this more in more detail but I'd say at a high level the way I feel that is some of it depends on scale. If you're like two developers who own the whole system that you're in like, you know, in a very small startup. The answer is very different to if you're a multinational bank with regulations and you know hundreds and hundreds of teams interacting with each other. I mean, you know, the big problem with auto updating to latest all the time is, when are you creating that artifact that are you testing something like are you creating something that's going to be tested in a test environment. Are you going to be able to reproduce that artifact again. I think there's some nuance here and it involves, you know, probably doing a mixture of both but choosing when in your software delivery lifecycle you do each of those activities. The most depressing answer from experts is there's nuance. It depends on the one hand and on the other hand. I'm broadly in the camp that you should pin your dependencies in source code and update them automatically. I don't like mystery dependencies showing up in production without warning and without record. That makes me deeply uncomfortable personally, but I recognize that it's a hassle. We are sort of like in, I don't know, like, not quite the pre history but we're definitely at least no further than the bronze age in terms of dealing with this stuff. We have technology but it goes blunt easily and causes a lot of a lot of hassle. And we just need to learn to grow the muscle to do it and that's just going to take a lot of time and be sporadic and uneven. But I do agree with Nigel's point that there's sort of minimum standards of hygiene you need to reach first. You need to have good testing in CI in place. You need to have smooth the road to production from source code changes. Those are the same capabilities you will need to automate upgrades. I will put an asterisk here about like the tradeoff and risks between waiting to upgrade versus upgrading too soon. And Sonotype have released their eighth state of the supply chain report a few days ago. It's worth reading. They do fantastic, fantastic research. Their position is that you should hang back a little, you know, one on two versions behind the pace or maybe some amount of time, I think would be a better way to do it. On the theory that if you're right at the bleeding edge, you will, you will get cut from time to time and that it's not worth the risk. I'm kind of on the fence about that. I think that the incidence of a vulnerability existing is far higher than the incidence of a supply chain attack being successful. So the balance of risks. What about general bugs too?  It should be working.  I think it's something to be said to staying on latest generally leads to a better experience. It's also because upgrading is not just like a linear function of the number of things you have to upgrade. It's exponential, right? Because there are interactions between the dependencies. So the longer you lead it, you know, like the larger that sort of Cartesian join of doom gets. So you want to you want to keep close to the edge. If you can Shopify, for example, we have the monolith, which is the main application that probably the largest Rails app in the world. And we keep that on Rails edge once a week once a week we upgrade to what is literally in the main repo of Rails, like we're not waiting to point releases or anything like that we're keeping up with it. Because we know that the upgrade pain is just too large. If we hang back for a year, like it would just just be catastrophic. And I can I can sort of look back at the earlier history of the company through through documents and and and get get commits and I can see that pain and I can see why we did it. Yeah, I just got off the call with a customer who's still on Red Hat 4 and is unlikely to ever get off because they they left it too long and now they have slides little bit of history that they have have to work around. Yep. You're muted. You're muted. The webinar guards are against us. No, still muted. This is how you know it's live everyone. Yeah. So I think one of the interesting things while she was working out her audio is a lot of this conversation around security issues and software supply chains. It often feels kind of one sided in terms of companies that are getting an awful lot of software sort of for free from volunteer maintainers who have been, you know, every time one of these vulnerability comes out. So it's like everyone has the pitchforks out for the main title.  I think something has to change about the producer consumer relationship with open source. Like there's a general assumption that it's software of a certain quality everyone should try and write good software but something feels out of kilter in society about the promises and commitments that people expect. There's a there's a really fascinating paper that just is currently in preprint SSR and the social science research network. It's a preprint server called tragedy of the digital commons, which, which is like written for a law journal but goes into kind of like the economics of it, you know, like the law and economics kind of situation and she makes exactly the same point which is that large software companies in particular are free writing off the community. In a big way. Her argument is that the sort of the ambient costs of security risks should be pushed back onto those companies to bear because they're the ones who are best able to bear it. Yeah. It's, I totally agree. Big tech loves open source like sharks love fish, you know, Did you see the I saw, can you guys hear me now sorry about that. Yes. Yes. But my laptop, the battery is gone. But anyway, I saw that legal letter that one of the log for Jay. Modern maintainers received and it was just like, Oh, for the love of God, like, he, he's like doing this for free and you're like telling him, giving him a legal letter to update and like from a company that's using his code for free. It definitely doesn't sit well. Doesn't seem morally right or something. I mean, I'm kind of in an interesting position here because I've been one of the champions for introducing MFA requirements for for software repositories, you know, where the authors need to have MFA enabled, because their packages are so widely used. And in the sense that's imposing a cost, you know, it's imposing imposing additional effort on the package maintainers who didn't didn't ask for it. Right. And I do feel bad about that but I then have to sort of take the utilitarian stance that the end consumers are far more numerous and for them the consequences are far more serious if if there's a compromise. It's, it's a tricky, it's a tricky thing but I think that the difference there is that like the end consumers can just involve other, you know, random open source developers who who didn't expect something nasty to come down the pipe as well as the companies who can bear the cost and should contribute back. Yeah. Yeah, I saw there was on PIPI they have some stats on who has converted to MFA. It's not like super impressive. It's like 20% of people that will eventually be asked be forced to have to have turned on MFA. Maybe some of them don't know about us or some of them don't want to do it and then just wait till they have to. It won't be a big deal. That's, that's largely what happened in Ruby. I know some of those authors because they work at Shopify. And I said, yeah, we agree with logic. We're just not going to do it until you make us do it because it's just, it's just work right. It's an additional thing to do. Yeah. Yeah. And what about like, I've seen, I saw a list of things that maybe open source maintainers can do to be more secure, but it was like a lot of stuff for someone to do. It was like, add scorecards to their repo. There was like, there was just a ton of stuff to do a course. Like I just can't imagine if you're doing this in your spare time that like a lot of people are going to do it. Especially when people often got into this because it was fun, you know, like, hey, I solved a problem in a fun interesting way and I want to share that with the world and I think I don't know if software licenses are the way it is or some kind of opt-in system. But I feel like there's got to be a way to distinguish between, hey, run, here's something fun and cool. Have at it. And I am deliberately building something that I would like to be part of a bigger structure and a bigger ecosystem. And I think that that's sort of the constant trade-off.  I think the sort of the coordination point or choke point, depending how you look at it is probably going to be the software repositories because they can set the terms. Under which they agree to distribute the software. And so if you don't like those terms, you are within your rights to take the software which is open source into running yourself. And within your rights to just distribute source from a website that you own. Like there's alternatives, like they're not as convenient, right? They aren't, but you know, that's the trade-off. Yeah, I think that's, and it's similar to, all of this reminds me of, I was a Debian maintainer back in the day when you were sort of in one of two big Linux camps. And I was quite shocked when I sort of moved to that point level of suddenly having all of these security processes enforced on me. But it was the right thing to do because that was the distribution center, you know, to all of these volunteers. Oh, and like, so a lot of these things where Debian community already had a lot of these.  A lot of these problems, I think, have been solved in smaller communities before we're just now dealing with them happening faster and at a bigger scale. And, you know, in tech, I feel like we love nothing more than to ignore the discoveries of the past. Yeah. And so what I'd say so what do you think there are the biggest challenges in software security or is it like we've been talking about how there's just so many challenges and it's just all of them together. But if you're going to give yourself a top one or two, what would be your favorites? Well, that's tough. This goes back to that earlier discussion about culture versus practices. There's this vast amount of latent risk out there. And we've just got to sort of chip away at everything that gives. We're pushing in every direction at once and anything that gives we push hard up because we're getting some progress out of it. We're retiring some risk from it. Building up those layers of security. Building it up and, you know, reducing the net risk for everybody, which is which is the sort of the goal, you know, that there's that problem that open source is basically a commons. Right. Like it's it's a kind of a resource that you can't exclude people from using but where if lots of people use it and that puts pressure on the maintainers it's rival risk as economists call it. And that's commons and they're difficult to govern the difficult to manage because you know everybody's an individual they've got different incentives to be selfish and the difficulty is finding those well positioned parties to be involved. So to their credit, I know we bashed up big companies but to the credit a lot of them are coming to the table or trying through the open source security foundation which I participate in open SSF.  Yeah, the trick is, is going to be like to your point here like, will it just seem like a loud crescendo to open source maintainers like here's a massive list of things that we can offer you. Where do I start. Like, is that the 10 point mobility plan is, is part of the open SSF way to secure open source. And do you feel like open source is one of the most important things to secure when we're talking about software in general. Oh yeah. Yeah, it depending who you ask it's it's Yeah, it's the sky blue. Only on sunny days. Yeah, it's it's everywhere now it's in pacemakers it's in nuclear power plants. Like there isn't there isn't a single critical or high, you know, high consequence piece of infrastructure, whether social or technical that doesn't rely on it. We have to like it's, it's the soft underbelly of the whole of the social economic system at the moment. And what do you think about regulation, because I know the US federal government is bringing in some new rules about espams and even vulnerabilities. And do you see that as a way to improve security of a product. Strictly, yes. This this is a good example of that argument from tragedy of the digital commons article that the cost should be pushed on to the large companies that currently free ride and have the resources to not free ride. And the US government is in a great position, because it's the single largest purchase or a software in the world to push push those standards down and to make them common. Once they become common than other consumers from those companies will say well you already have that capability I demanded also and that creates a sort of a flywheel effect. But in terms of regulation of open source software itself. I think big companies like your regular maintainer at home on a weekend.  And I think what is a rather hairy thread mix metaphors and we don't value maintenance enough in society. And I think this is sort of part of the problem that, you know, and is why I think right to repair movements and all of these things are so important that, you know you work in lots of, we have a culture in software development that I think reflects society in general at the moment which is, it is considered better to launch new things than to iterate on existing things. And the job of maintainers is to iterate on the existing things and I think the healthiest software engineering environments I've ever worked in have been the ones where really senior folks are sort of proclaimed, you know, lauded to look at systems make small incremental changes to them over time keep them going in the right direction, and that that's recognized as valuable. I think this is the whole problem. We recognize value maintainers anywhere near enough. And so they feel at the end of the supply chain when we should be going, you know, know you're a critical part of this whole process and you know, if I could wait one it would be around us to maintain the act of maintenance more. So that big companies did want to participate in it so that they, you know, reached out to maintain projects with respect, you know, I think Google does a reasonably good job of this like we've had Google reach it is a security vulnerability and something you ship, you know, we've seen some of our users have it, you know, they basically wield a big stick and go if you don't do something about this in 30 days or 60 days or whatever we'll just we'll shout it from the rooftops and they can because they Google I think there are ways to do that sort of encourage people to do the right thing, but fundamentally we've got to value the act and process of maintenance more everywhere. And I wonder if like government funding could help I know like obviously the 10 point mobility plan should improve security and that's using money. I know maybe to there was talk about resetting putting funding towards resetting to FA shock and public repositories. But do you see it. Do you think that maintainers could get paid for improving security of product obviously selective products like that are used in critical systems, like what do you think that would that's a solution or is that just it's just it's not it's not going to some maintainable in the long run. I'm concerned that it goes back to that problem of metrics that people will be, you know, the incentive is just to do what what the funder says. And that will attract people, you know, like the story of the British trying to get rid of Cobras in India, and they pay people to bring in Cobra heads and people just started breeding Cobras. And there's something similar where there's gun buybacks and people are just three be 3d printing guns on mass and bringing in boxes of 3d printed guns and making money that way. I'm concerned about that. I think where government has a role in terms of funding at least would be on what you might think of as sustainment activities. So, things like subsidizing or fully funding training, right making it freely available to as many people as you know, encouraging colleges and universities to pick it up as part of their curricula. Things like, you know, shared resources for software repositories shared resources for open source projects that need a security review a lot of things that the open SSF is already doing can definitely be scaled up with government funding. I think about punitive approaches to like, and this is something I'm always curious about, because it feels like most of the huge companies that suffered data breaches that were honestly pretty derelict in terms of. Oh yeah, I think they just haven't been punished, like either markets or by governments. And why would you invest in security when it doesn't actually matter. I'm a bit of a, you know, like I consider myself a centrist. I used to be a libertarian, but I'm about to sound like a raving loony lefty but because I think there is far too many things in corporate malfeasance, in which the punishment is a fine, whereas it should be criminal time for the executives who authorized or who failed to authorize, you know, some activity. Because that's the only thing that actually gets their attention. If you get fined, it doesn't fall on the people who made the decision. It falls on the shareholders. Exactly. Or the people who didn't have control. Like Optus is a good one. Yes. Like you have a company that literally litigated, you know, pressure lobbied the government to make sure companies weren't accountable in these sort of situations. And then now all of these millions of people have their data spread. Including me, my passport number got stolen. Actually, I was listening to the Security Weekly podcast and at the end of it, they talked about insurance as a way to drive companies to do more to be better at security. And it can be a more effective way than compliance or that like when you when you have a data breach and you realize you're not insured and you have to pay a lot of money to maybe for on on people so suing you or even to get back to where you were if you if you've lost data. That that is a quite an effective way. Why not why not both.  You know, the consequences of of data breaches are dire. The consequences of lackadaisical security are only going to grow worse as time goes on and as all matters somehow becomes programmable. Basically, then this stuff really matters and I think this argument that like, oh, but the corporate veil is sacrosanct. It's just like the corporate veil is there to deal with, you know, questions of who owes debt to whom, like, who can be who who is liable for how much. It didn't give you like a magical get out of jail car that was never the idea. So as I said I sound like a raving money on this point because I'm so frustrated by companies that walk away with a fine and the executives are still there. Right they don't get sacked. They just go like, oh well that's the cost of doing business and that to me is psychotic. Yeah.  There's not enough accountability at the cover level. Absolutely wouldn't even that one. We rise up and smash the system to death. We're going to do it. Right, no to all countries. Yeah. On that, I think we're going to announce our prize. Hillary, do you want to? Now that we've done the rally. Yeah. We've gotten to where we were meant to go. So the prizes are announced there in the chat. We have here. Jojo Dutta, who gets a free lunch. He's sharing on on the streaming platform. We have Arthur courage. He's a free lunch. Jinsu prize pack. Arjun just she price pack. I'm, I'm so sorry. I'm butchering these poor people's names. Caitlin. Oh, oh God, Caitlin. I'm so sorry. You get a price pack. Hunter. Cune price pack. And Hillary is going to be reaching out to everybody over email with, with your details to send it on your send it on to you. But I hope everybody enjoyed our talk today. I loved it. I'm so sorry about my. My speaker issues. It happens. You guys were such pros. You continued on the conversation. Yeah. The other way to put it is that we talk too much. And thank you for being such wonderful guests. Shark and Nigel. It was like really nice to talk to you. So it's bye from our guests. You guys can say bye. Hi. Thanks for having us. Thanks everyone. And it's by from me. So thanks everybody for joining. We'll see you at the next monthly. Thank you. Bye. Thanks. Bye. Thanks. Bye.