Let us go to the next example. So, here we have a vertical frictionless piston cylinder arrangement. This contains initially 2 kg of water at one bar. So, the piston initially rests on these two stops. And when the pressure inside reaches 3 bar, the piston will begin to move. So, the volume when the piston is on the stops or the volume occupied by the water when the piston is on the stops is given to be 250 liters. Now, we transfer an amount of heat equal to 4500 kilo joules. We are asked to determine the final state of the water and we worked out. And the initial state we have we have the volume which is known. So, V1 equal to 0.25 meter cube. Mass is also known 2 kg. So, which means the specific volume is known at the initial state and the pressure is also known at the initial state. So, with these two pieces of information, we should be able to locate the state initial state. So, the specific volume at the initial state is 0.125 and the pressure is 1 bar. So, you go to the pressure table the steam table and you can see that Vf is equal to this and Vg is equal to this. Since the given specific volume lies between Vf and Vg, the initial state is a saturated mixture. So, we can now show this on a PV diagram like this. So, this is 100 kPa. So, the initial state is a saturated mixture which looks like this. Now, we add heat to the contents of the cylinder. Notice that the volume will remain a constant until the pressure inside reaches 3 bar. Because at that pressure the piston will start to lift. So, the working substance undergoes a constant volume process from 1 bar to 3 bar or 300 kPa. So, let us say that this is 300 kPa. So, the working substance undergoes a constant volume process from 1 bar to 3 bar. Let us denote this state as state 2. So, what we will try to do is determine the amount of heat that is required to go from state 1 to state 2. Notice that at state 2, once again two pieces of information are known to us that is the pressure which is 300 kPa and specific volume V2. Remember V2 is equal to V1. So, using these two pieces of information, we can actually locate the state. So, for process 1-2, if you apply first law, we get delta E equal to delta U again no change in ke or pe. W1-2 is 0 because it is a constant volume process displacement work is 0, there is no other form of work. So, the heat that has to be supplied to go from state 1 to 2 is given by this expression. So, at state 2, as I said before, P2 is 3 bar and V2 is equal to 0.125. So, we go to the pressure table corresponding to 3 bar, we get Vf equal to this, Vg equal to this. Since V2 lies between Vf and Vg, state 2 is also a saturated mixture state. So, when I showed state 2 to be like this, it was an educated guess and that it is a saturated mixture. But now, with the information that is available, we can precisely state that state 2 is a saturated mixture and we can evaluate the dryness fraction using the known volume, a known specific volume like this and that comes out to be 0.2048. And the specific internal energy may also be evaluated at state 2 and that comes out to be 967.15. So, the heat that has to be supplied to go from state 1 to 2 is 794.238 kJ. So, that means of the total 4500 kJ that is supplied, 794.238 goes to raising the state from 1 to 2. Now, we supply the reminder of the heat to reach the final state. Notice that once state 2 is reached and the pressure becomes 300 kilopascal, if I supply heat any further, the piston begins to lift. So, if I look at any intermediate state, let us say this is an intermediate state, if I look at the force balance on the piston at any intermediate state, the forces on the piston are the following. One is pressure force from the contents of the cylinder in the upward direction. The next one is P atmosphere in the downward direction and the pressure due to the weight of the piston which is also acting downwards. However, notice that these two quantities the P atmosphere and the weight pressure due to weight of the piston remain constant during the process, which means that the contents of the cylinder undergo a constant pressure process as we supply as we continue to supply heat, which means that the process looks like this. We do not know where the final state is going to be, whether the final state is a superheated state or whether it is a saturated vapor state or whether it is still a two-phase mixture or not remains to be seen. So, that depends on the amount of heat that we are supplying, but this is the process line. So, that gives us an idea. So, now, we apply first law to process 2-3, we get delta E equal to delta U equal to q 2-3 minus W2-3. Notice that displacement work in this case is non-zero, it is a constant pressure process. So, PDV integral PDV is easy to evaluate, P comes out of the integral. So, we can write this first law in this form and if you rearrange this expression, basically what we are going to do is take this term and combine it with this term here and bring the U2 term to the right-hand side. So, we rearrange it like that, then we get the specific enthalpy H3 equal to U2 plus P2 V2 plus Q2 3 divided by M. P3 is equal to P2. So, I have used the fact that H is equal to U plus PDV. So, now, once again we have two property values at state 3. One is the pressure which is 300 kilopascal, the second one is a specific property which is the specific enthalpy. So, if I plug in the values, I get the specific enthalpy to be 2857. So, we now go to the pressure table and we notice that Hg corresponding to 3 bar is actually less than H3 which means that, so Hg corresponding to 3 bar is less than H3 which means that state 3 has to be a superheated state. So, we go to the superheated table now and we can get the specific volume at state 3 to be equal to 0.7103. Let us just quickly take a look to see how we use the superheated table. So, we have been given the pressure to be 300 kilopascal or 3 bar. So, here we have 3 bar and superheated table, superheated steam 3 bar and we are also given the specific enthalpy to be 2857.53. So, 2857.53. So, we go down the enthalpy column, 2857.53 is going to fall in between these two entries. So, we interpolate and get the final values that we require. Linear interpolation in this case is sufficient or if you have software tools by entering just by entering the pressure and the specific enthalpy, you should be able to get the final values. So, we interpolate to get them specific volume at state 3 to be equal to this. So, the work interaction for entire process 1, 3 is equal to work interaction during 2, 3 because w12 is equal to 0. It is a constant volume process 1, 2. So, we can evaluate the work interaction during the process to be 351.18 that is what we have been asked to find. Let us just check. So, we have been asked to determine the final state. We have determined the final state to be A and superheated state. And we have also evaluated the work done during the process. So, again, when you solve problems like this or do an analysis of problems like this, you must always remember the way in which we developed the material. For a two-phase mixture, first identify the two properties whose values are known. And once you identify them, we locate the state. Once we locate the state, we can then evaluate the property, any other property whose value is required. So, that is the sequence that we follow. Let us go to the next example which is somewhat more involved. So, basically we have insulated piston cylinder arrangement with a metallic partition in between. So, this is a metallic partition, very thin partition does not store any energy. It is rigid, so it remains flat and it does not store any energy, but it is a metallic partition, so that Ta equal to TB all the time. So, the temperature on both sides are always the same. So, that is what the metallic partition does. So, the initial state is given. In compartment A, we initially have steam at 5 bar, 180 degree Celsius. You know that since pressure and temperature are given, that this must be a superheated state because I think it is easy to follow. By now, you should be able to do that. So, the volume is also given. Notice that volume of compartment A is given to be 0.2023 meter cube. And as the process takes place, the volume of compartment A remains the same because the metallic partition is rigid and remains so. So, the working substance in A undergoes a constant volume process. So, that means we can infer from the given information. Compartment B initially has a volume of 0.2 and contains 2 kg of a saturated mixture of liquid water and water vapor. So, then the information that is given is the specific volume is known initially and it is also given to be a saturated mixture. So, we now add heat to this until the pressure becomes equal in both compartments. Bear in mind that the temperature is always equal in both the compartments, but now the pressure is also at the final state the pressure is also become equal. And we are asked to calculate several quantities here A through D and also the amount of heat that is transferred. So, the initial specific volume in compartment B is 0.1. It is initially at 180 degree Celsius because this is initially at 180 degree Celsius. Since the temperatures are the same, this is also at 180 degree Celsius. So, the temperature is given to be 180 degree Celsius. The specific volume is also given. So, you should be able to determine that this is indeed a two-phase mixture and also that the saturation pressure corresponding to this temperature is 10.02 bar. Let us just quickly go to the temperature tables and verify this. So, this is the superheated table. So, we have temperature table now and the temperature is given to be 180 degree Celsius which is this. So, the saturation pressure is 10.02. Notice that the specific volume of the saturated vapor is itself 0.1940. This is 0.001. So, the initial specific volume lies between these two. So, it is a saturated mixture and since it is a saturated mixture, its pressure is equal to the saturation pressure. So, the initial pressure in compartment B is thus equal to the saturation pressure corresponding to 180 degree Celsius which is 10.02 bar. So, we can then retrieve the following values from the steam table and the initial dryness fraction in compartment B may be evaluated like this and 5 bar 180 degree Celsius you should be able to easily show that this is that the state is superheated and we may then retrieve the following values from the superheated table. 5 bar 180 degree Celsius. Let us just see once how this is done. 5 bar 180 degree Celsius. So, this is the location in the table V1 is this and U1 is also equal to this. Now, the mass contained in compartment A may be evaluated from the specific volume and the volume of the compartment itself by using this relationship. So, it comes out to be 0.5 kg. Now, if you look at the pressure in compartment B, this is due to atmospheric pressure plus pressure due to weight of the piston, both of which remain constant during the process which means that the working substance in B undergoes a constant pressure process. Working pressure in I am sorry working substance in compartment A undergoes a constant volume process and the working substance in compartment B undergoes a constant pressure process. So, if we were to sketch the process at least qualitatively on a PV diagram, let us try to do that here. So, if we sketch this qualitatively on a PV diagram, so this is 10.02 bar. So, initially, this is the state in compartment A and this is 5 bar and the initial state in compartment B is over here. So, this is 1 comma A. So, the working substance in B undergoes a constant pressure process which looks like this and the working substance in A undergoes a constant volume process which looks like this until the pressures become equal. So, this will be the final state. So, that is state 2. So, now if you look at the information that is available about the final state, pressure in compartment B remains constant. So, the final pressure is equal to 10.02 bar. Now, the final pressure in A is also equal to 10.02 bar because the final pressures are the same. Now, the specific volume in compartment A remains the same because it undergoes a constant volume process. So, we have two property values at the final state 10 bar and 0.4045. So, final state in A is superheated. This can be easily established and the final temperature comes out to be 607 degree Celsius, again from the superheated table with linear interpolation. Now, since the temperature in both compartments are the same, final temperature in B is also 607 degree Celsius and as this illustration indicates the final state is the same in both compartments. So, there is no separate 2B and 2A. The final state is the same because it lies at the point of intersection of this isobar and this isochore or constant volume line. Now, I take compartment A and B together as my system. So, we take this to be our system and apply first law. Since the partition does not store any energy, I may write delta E equal to delta U which is nothing but the internal energy of the working substance in A and B. There is no storage of internal energy in the partition and there is no KE and PE change also. So, delta E becomes equal to delta U equal to Q minus W. There is no displacement work in compartment A because it is at a constant volume, but there is displacement work in compartment B because it is a constant pressure process. So, we may evaluate the work interaction very simply using this expression and it comes out to be 610.218 kJ and the internal energy change may also be evaluated quite easily and that comes out to be 3576.87. So, the total amount of heat that is transferred comes out to be 4187.088 kJ. So, once again you can see that with the given information, we try to draw a PV diagram or any other coordinates. PV is simple. So, we draw a PV diagram, try to locate the stage and also try to sketch the process at least qualitatively on this diagram, fill in the information as you keep proceeding with the analysis. Initially, we fix the states and try to put in as much information into this diagram as possible with the given information from the problem statement. Then as we go through the analysis, we fill in more and more information so that you get clarity. So, once you have the system identified and then you also enter as much information as possible into the PV diagram, the analysis becomes that much easier. So, the last example that we are going to look at is this one here. So, we have an insulated rigid vessel of volume 500 liters. So, this is the insulated rigid vessel volume 500 liters which is initially evacuated. It is connected to a line in which steam at 20 bar 400 degree flows through a valve. So, here is the line in which steam at 20 bar and 400 degree Celsius flows it is connected through a valve to this line. So, we open the valve and steam is allowed to slowly flow into the vessel until the pressure inside is the same as the line pressure which is 20 bar and then we close the valve at that instant. We are asked to determine the final temperature inside the vessel and the mass that enters. Heat loss may be neglected because it is given to be insulated. KE and PE changes may also be neglected. You may recall that we had already looked at an appropriate system for this case and that system looked like this. So, the system looked like this. So, this is the mass. So, this is the mass that enters from the line which we will label as M line. So, that is the initial system. In the final state, this part of the system boundary diminishes altogether and we have only this part that is left. So, this was discussed in the beginning of the course when we discussed definition of system and different examples for system. So, now, so that is our system. So, if we apply first law to this system, delta E equal to delta U, no KE and PE change equal to Q minus W. Q is 0 because there is no heat loss and the vessel is completely insulated. Now, notice that W is not 0. There is defamation in this part of the system boundary, no defamation in this part of the system boundary, but defamation in this part of the system boundary at constant pressure. So, the displacement work may be evaluated quite easily. The constant pressure is nothing but P line. And as I said, you know the part of the system boundary in the line disappears altogether at the end of the process. So, that means the volume occupied by the system, this part of the system is 0 at the end of the process. So, we end up with something like this and so, notice that U1 is the specific enthalpy of the, notice that this term here delta U, this is actually M times U2 minus U1 where M is the mass of the system. But in this case, since the vessel is initially evacuated, the mass of the system is equal to whatever mass that is going to enter from the line. And U1 is equal to U line, this is the specific internal energy of the mass that is going to enter from the line. So, U1 is equal to U line. Or in fact, you may, if you wish, you may actually rewrite this itself, delta U for the system may be written like this delta U in the, for the system, part of the system in the line plus delta U in the vessel. Since M is equal to 0, since this is initially evacuated, we take that part to be 0. So, basically we end up with something like this. But notice that finally, the steam that was in the line will actually enter and occupy the complete vessel. So, you have to be careful with how you do the analysis. So, we expand this U2 minus U1 like this. And if we rearrange this, take this term to the left-hand side and rearrange, we get something like this.  That is the enthalpy of the fluid that is flowing in the line. So, the specific internal energy of the steam that is finally in the vessel is actually equal to the specific enthalpy of the steam that is flowing in the line. So, for the steam flowing in the line, the pressure is given to be 20 bar, temperature is 400 degree Celsius. So, we can get H line to be equal to this from the superheated table. Now, for the steam that is finally in the vessel, again we know two values for two properties, we know that the state is superheated. So, final state of the steam of the working substance in the vessel is superheated. So, we can easily get the final temperature to be 575 degree Celsius. Notice that the steam in the line flows at a temperature of 400 degree Celsius. However, the steam in the vessel is at a higher temperature 575 degree Celsius, because of the fact that the specific internal energy of the steam inside the vessel is equal to the specific enthalpy of the steam that is flowing in the line. So, basically what has happened here is that the work that was done by the steam in the line to push this amount of steam into this is also now included in the specific internal energy of the steam here. So, there is work that is being done and there is also internal energy of the steam. So, the work that is being done is now being added to the internal energy of the steam and that is why the steam here is at a higher temperature than the steam in the line. So, what we will do in the next lecture is start our discussion of first law of thermodynamics for a control volume. So, so far we have looked at first law for a system undergoing cyclic process as well as a non-cyclic process. And we have applied first law to analyze many, many different examples. Some of them involving ideal gases, some of them involving two phase mixtures of refrigerant or steam or water and water vapor. So, for all these problems we could use the system approach quite comfortably and complete the analysis. But there are certain problems for which a modification of the system approach is required to make the analysis spot easier. We will not be deriving a new form of the law, we will simply modify the system approach to come up with an alternative form of first law that can very easily be used for the analysis of these types of problems. We will take it up in the next lecture.


how Prometheus indexes its data and why you should care. Do you ever wonder why a simple promcule query like this takes more time to execute with more instances to monitor, even when the instance level is not in the query? Or why does the performance slows down every time you query data with an increased time range? This talk will give you an intuition for query performance by understanding how Prometheus indexes its data. A brief about me. Hello, everyone. I'm Harkishan Singh. I live in Bhuvaneshwar, which is an east coast of India. I work at a software engine in a time scale and contribute to Prometheus upstream regularly while developing and maintaining prom scale, which is an open source observability backend that can store Prometheus metrics and open telemetry traces. When I'm not working, I read books and play computer games. That's about me. This talk will cover three topics. We'll start with understanding the Prometheus data model, then learn about the indexing strategies that Prometheus uses to index its data and finally learn the querying execution flow with the help of Prometheus indexing strategies that we learned in part two and the effect of high cardinality on it. Let's begin with understanding the Prometheus data model. Prometheus uses a simple data model that contains labels, values and timestamp. In this example, we have a metric go underscore go routines, which has two labels. Instance equals C advisor, calling 8080 and job equals C advisor, which has a value 125 followed by a timestamp. Now, what are series? Series are basically sets of labels. Now, if you change one label or even its label value, it's a completely new series in Prometheus data model. For example, the third label over here, which is instance, has its value changed towards the right. This leads to completely new series for Prometheus. What Prometheus index cares about is labels and time. These tools are collected when Prometheus monitors a target. The value part in the Prometheus data model, which we learned previously, is not what Prometheus index cares about. On a high level, let's see the indexing strategies that Prometheus uses. Let's start with understanding what a Prometheus block is. A block in Prometheus is a basic unit of data storage that stores two hours worth of data. Let's see how a block looks like. On a high level, the block contains two things, samples data and index. Sample data is the data that Prometheus scrapes from the targets and stores it inside the chunks directory. Index is the actual indexing process that Prometheus uses for query evaluation or for indexing its data. This is what we will learn about in the next slides. The next is method or JSON, which is the metadata about the block. And finally, we have Tomestones, which contains a deleted series along with information about its deletion range. Let's learn about what chunks are. Chunks are a collection of samples in a time range for a particular series. This organization of data makes it easier for systems to retrieve samples for a particular series. If the index can figure out which set of chunks belong to a particular series, we will cover this in the next slide. Now let's see what an index file is. Prometheus index file contains two types of indexing. The first is postings index and the second is series index. A posting index is a relationship between labels and a set of series that contains that particular label. For example, name equals up. This label is contained in two series. And similarly, the next example is instance equals 9091. We have one series in our example which contains this particular label. A series index is a relationship between series and set of chunks that belongs to that particular series. For example, the first series contains two chunks. The second series contains three chunks. None of these chunks are shared between two series. Rather, each chunk is specific to the series itself. Let's see how the blocks are placed inside Prometheus DSDB. Blocks in Prometheus DSDB are collection of index and sample data which we discussed previously. Now imagine Prometheus gets a query say up with a label as job equals from which has a start with two hours and 30 minutes and ends at five hours. Now block two and block three overlap with the query's time range which means we will consider block two and block three for the evaluation of the received query. Let's understand the query execution process on a very high level. But first, what is a query? A query is formed of two things, labels and a time range. Over here, the labels are name equals up and the job is from and the instance is 9090. Let's understand a basic query execution strategy. So a query has two things as we learned which were labels and time. The first step uses the time component of the query which basically means we see the query's time range and figure out which block overlaps the time range of the query and then we consider those blocks for query evaluation. Next, we use the labels part of the query to find out which series contains the query's label. This is done using the post-exindex which if you recall was a relationship between labels followed by a set of series that contains that particular label. After step two, we have a list of series that satisfies the query's label. Hence, we move to the next step which is looping through each of the series list which we've got from step two and using the help of series index which if you recall was a relationship between series and a set of chunks that belongs to that particular series only. So while we loop over the series using the series index we find the chunks that belong to that particular series and then retrieve samples from the chunks in step four. For understanding the querying process it is important to understand that this test that I said happens for each block then each series and finally each chunk. This means any delay on step one will have multiplicative effect on the following steps similarly for step two and so on. For example, if there are a lot of blocks to consider for a query evaluation that will slow down the series because we have to go through each of the index file in the block to read the respective postings index and the respective series index. Let's look at some query examples to understand the query execution process better. Now imagine that Prometheus gets a query up with a time range. The first step is to find the blocks that overlap the query's time range. Say block one and block two were those blocks which overlap the query's time range. Next we use the postings index to find which series satisfy the labels of the query. Over here the query as up which in other words is name equals up. So we see the postings table and find out which series contains this particular label. In our example we have two series for that. In the next step we loop through each of the series which we got from step two and using the series index find the set of chunks that belong to that particular series. For example, chunk one and chunk two belong to series one. In the same way this will happen for the second series as well. And then finally we try to samples from only those chunks that overlap the query's time range. Now, let's focus on the postings index to understand a more advanced query execution. Let's add a label job equals prom to our previous query which was up. This query has two labels now. One is name equals up and the other one is job equals prom. When this query is given to the index reader the index reader goes inside the index file and looks at the postings table and tries to find out a match between the labels of the query and the labels inside the postings table. Over here we have two labels. So the first match is received at the first entry which is name equals up which has three series and the second match is received at the second entry which is job equals prom which contains two series. Now if we see the promql expression it needs a series that contains name equals up and job equals prom which means there's an and condition in promql. Since there's an and condition we do an intersection between the series which we got from postings table. Intersecting the series of the first two entries will give us series two and series three as the result. So the result of the promql query would be samples of series two and series three. Let's see another example with another label instance equals 9090. Now this query has three labels. First is name equals up the second one is job equals prom and the third one is instance equals 9090. So the index reader goes inside the postings table and tries to find a match for these three labels. It gets a match for the first three entries because these three entries satisfy the queries labels. Now what the query wants is a series that contains name equals up and job equals prom and instance equals 9090. So we do an intersection between the three entries and we get series three as the result. So the result of the promql expression would be samples of series three that lie in the range of the promql's expression. Now let's learn how high cardinality affects the situation. But first let's understand what high cardinality is if you recall the previous slides towards the start. We learned that every new value of a label creates a whole new series for Prometheus data model. That's what is high cardinality in labels. So when you have multiple label values for a particular label name that creates a lot of series in Prometheus system. In other words, having lot of label values for label names will create lots of series for the Prometheus. So under high cardinality for each block in point two the index reader has to go through a long list of tables in the postings table to find which series satisfy the labels of the query. Now there is high label cardinality which means lots of series are in the Prometheus system. So the result of step two will give us a long list of series that satisfy our given labels. Now in the step three we have to look through each of the series in the long list. Which we got from step two. And then for each series find the chunks that belongs to that series. And then in step four retrieve the samples from each chunk. Retriving samples from chunk is a C cooperation on disk and if the block is memory mapped or not memory mapped this can be expensive. Similar to the block is memory mapped this can be expensive. Similarly a query with a long time range will involve lots of blocks which overlap the queries time range which means you have to read index file from each of those blocks that overlaps the queries time range. This will cause the following steps to slow down since step two has a dependency on step one. A long range in query also means that we have to loop through lots of chunks which we receive from step three which overlap the queries time range. This can take good time. And this is why a simple promql query without lots of labels when executed in a high cardinality system or having long time range in queries affects the query performance and slows them down. And with this we complete the talk. And we are hiring engineers that are excited about building high performance systems for observability and time series use case. We work on prom scale which is a backend for observability data which uses timescale DB a time series database built on top of Postgres which is operationally mature and SQL compatible. We are also open source and fully remote company. If you are interested please apply at timescale.com slash careers. Please write your questions in the event slack channel. Thank you very much.


What is up guys karma medic here and welcome back to another dose be new to the channel then hi My name is Nasser and I'm now a fourth year medical student studying at King's College London according to my extremely neat and tidy year For finals study exam timetable It looks like we're gonna be studying a little bit of cardiology today And then probably some dermatology your nose and throat and ophthalmology as well So if that sounds interesting to you make sure you grab some coffee or some tea Don't forget to grab your snacks as well So you can stay energized for the entire session and take your phone and put it somewhere far away from you where you can't see it Okay, I'm gonna put it under my bed and that way I'm not gonna be tempted to check it. All right without further ado Let's get started. All right guys.  I hope you guys enjoyed watching this video and actually got some good studying done yourselves If you did enjoy it Please don't forget to leave a like on it and I'll subscribe to my channel to more content from me in the future Also, feel free to watch all the other study with me on my channel I'll leave them linked somewhere here on the screen and yeah, share them with your friends If anyone else is looking for a study buddy during this time and that's it for me I'll see you guys in the next one face


Hi everyone, welcome to securing your container native supply chain with Salsa at GitHub and Tecton. Hi everyone, I'm Laurent. I'm a security engineer at Google. I work on the OpenSSF scorecard project and supply chain security. And I'm Priya. I'm a software engineer at ChainGuard. I work on open source projects like Sixdoor and Tecton, which we'll be talking about today, and a bunch of other open source projects as well. So you've probably heard a lot about software supply chain security in the news recently. As the graph shows, attacks are on the rise, and it's becoming really important to start to understand how you can secure your supply chain. So let's take a recent attack as an example. The NPM caller package attack. The attack happened just a few months ago, and one of the maintainers decided to add an infinite loop in the package. The code was never changed in the repository itself. The maintainer pushed directly to the NPM registry. Around 9 million projects depend on this package, either directly or as a transitive dependency, which is really scary. As a developer, it might be intimidating to know where to start when it comes to securing your supply chain. So in this presentation, we'll discuss practical steps you can take to start improving the security of your supply chain. So the good news is that if you already used Tecton or GitHub workflows today, there are a few easy steps that you can take to start securing your pipelines today. So that's what we're going to be talking about in this talk. Let's jump right into it. So a quick agenda for today. When discussing supply chain security, it's important to have some metrics or a framework to actually quantify how secure your supply chain is. So that's why we're going to start by talking about Salsa, which is the framework we're going to be using to determine how secure our supply chains actually are. Then we'll jump into talking about Sigstore, which is a project we use for signing and verification. And at the end of the talk, we'll talk about how we bring Salsa and Sigstore together to achieve higher security levels in both Tecton and GitHub workflows with demos for each of those platforms. So what is Salsa? Salsa is an acronym that stands for supply chain levels for software artifacts. You can think of Salsa as a framework or a checklist, basically a list of things that you want in your supply chain depending on how secure you want it to be. Salsa is not a tool or a service. It's more a set of guiding principles. Some key principles about Salsa include the following. Artifacts should be signed. And artifacts should also include metadata or so-called Salsa provenance about who and how the artifacts are created. Now, you might be wondering why we don't just use signatures. And the reason is, signatures do not protect against all sorts of attack that happen on the supply chain. Let's take again the example of the NPM caller attack. As we said earlier, the NPM maintainer pushed directly to the NPM registry. So the maintainer had access to the credentials. The maintainer would probably have access to the signing key as well if signatures had been used. Salsa provenance solved this problem by including who created an artifact and what source code was used to create it. So in a nutshell, Salsa provenance provides the following benefits. It allows tracing an artifact back to its origin, including the exact source code, repository name, hash commit, and branch. So the Salsa framework has four levels ranging from level one to level four. It's meant to be incrementally adoptable and it's a set of security guidelines established by industry consensus. Level one is supposed to be the most achievable level while level four represents the ideal end state. Level four can be difficult to achieve, so levels two and three are meant to be stepping stones on your path to achieving Salsa level four in your secure supply chain. Depending on your build system, you can start making progress towards Salsa level two and Salsa level three today, which is what we're going to be talking about. So a quick overview of Salsa level one. Salsa level one is the most achievable level with only two requirements. The first is that your build process is scripted, and the second is that you have some kind of provenance available, some sort of metadata about how your artifact was generated and maybe what also went into it. Salsa level two builds on top of Salsa level one and has some additional requirements. So this is where we start getting a little bit more secure. Salsa level two requires that your source code is an aversion control system like GitHub. Hopefully you're already doing that. It also requires that your builds are built in a service and that provenance is service generated. Provenance should also be authenticated, which means it needs to be signed so that end users can verify that the provenance for the artifact they're looking at is coming from where they expected to come from. So now that we've talked about the framework we're going to be using to evaluate how secure our supply chain pipelines are, how are we actually going to start implementing these Salsa requirements? So this is where Sixter comes into play and both of our demos involving GitHub and Tecton later in this talk are going to be using Sixter under the hood. So Sixter is an open source project aimed at making signing and verifying software free, easy and accessible. And how does Sixter accomplish this? It provides a few tools and services which are available for public use. And the first tool that it provides is called Cosign, which is a CLI tool and library used for signing and verifying software artifacts. This could be things like OCI images, espoms or provenance. One of the services that Sixter provides is called Fulcio, which is a certificate authority service that issues short-lived code signing certificates. It also provides a service called Recort, which is an append-only transparency log for storing signatures, certificates and provenance. But why do we use Sixter instead of traditional signing methods? What kind of problems do the Sixter actually solve? So the main benefit of Sixter is that it eliminates the key management problem. So we have a diagram of a traditional signing situation here, where we have a maintainer who holds on to a public-private key pair, signs their piece of software and then distributes it to an end user. The end user is responsible for verifying that software before they actually use it. But there's a few issues in this scenario. First, it requires that the maintainer holds onto the private key and keeps it safe for long periods of time, potentially years on end, which can be really difficult. What if that private key gets lost or ends up in the wrong hands? It's really hard to then revoke old signatures. It also means that the maintainer is responsible for distributing the public key to end users, figuring out how end users can get their hands on it. A lot of times, instead of verifying signatures, end users just choose to use the software without doing the verification because it's not easy to do the verification. So this is where Sixter comes in. It solves this key management problem so that maintainers no longer have to keep track of private or public keys. But how does this work? So you can see we have this updated diagram now, which includes the Sixter tools and services that I had mentioned earlier. So instead of holding onto a private key pair, the maintainer actually just has to request a certificate from the full certificate authority. This certificate is a code signing certificate and contains and is bound to the identity of the maintainer. In this case, it's the maintainer's email address. The certificate also embeds the public key that was used to sign, that is associated with the private key that was used to sign the artifact. And the signature is bundled along with the certificate and stored in the Recor transparency log. This is really convenient because the log is public. So when the end user attempts to verify the software artifact, they can use the Cosign CLI tool, which under the hood will retrieve the correct entry from Recor and do all the verification for you. All the end user has to do is decide if they trust the identity that is embedded in the certificate. So the nice thing about full CO is that both people and systems can request full CO certificates. People can prove their identity by signing in with an email address. So this would be like a sign in with GitHub or a sign in with Google type flow that you might have seen on different websites yourself. Systems can also authenticate and request full CO certificates. So workloads can use the Spiffy S with specification. And there's also support for using Kubernetes service accounts and GitHub actions invocations. So we're going to be using these last two in our demos later on in this talk. So how do we bring Salsa and Six Store together to actually start securing some build systems? So we'll take Tecton first and we'll talk about GitHub after. So what is Tecton? This is a big question and there's a lot to Tecton. So in the interest of time, I'm just going to cover the important bits for today's talk, but I would highly encourage you to go learn more about Tecton if you're interested. For now, all you really need to know is that Tecton is a continuous delivery system built on Kubernetes. It leverages custom resource definitions to run tasks and pipelines on your cluster. You can kind of think of Tecton just as a CICD system where you would do anything you would normally want to do in CICD, including running unit tests, running integration tests, building some sort of software artifact and then storing it somewhere for your end users to be able to use. The basic unit of Tecton is the Tecton task, which is you can deploy your Tecton task to your cluster. If you look on the right side, we have some sample YAML for a Tecton task. If it looks like a pod or it reminds you of a pod specification, that's because the Tecton controller is responsible for turning this task into a pod so that it can actually execute in the cluster. You can instantiate this task with the TKN CLI tool to turn this task into a task run. Task run is actually executed in the cluster and we'll be doing this in the demo later on in this talk. So what do we know once the task run has completed? Well, there are a few key pieces of information. First, we know whether the task run was successful. We also know what steps were run and exactly what arguments were passed in. And then finally, we know what artifacts may have been built in this task run. This is really useful when trying to achieve certain salsa levels. We know exactly what was run so we can put that into our salsa provenance and we also know what artifacts were built so we can generate provenance for those artifacts and also try to sign them. So how do we do this? This is where Tecton chains comes in. You can think of Tecton chains as a supply chain security manager for Tecton. It leverages six store under the hood to sign artifacts that are generated by Tecton and also generate signed provenance. Here's a little diagram, I drew of how this works. Basically, you have your cluster running and you have Tecton pipelines, which is the core Tecton project running in your cluster. When you start a task run, the Tecton pipeline project is responsible for executing that task run. Meanwhile, Tecton chains is observing all the task runs in your cluster and once it sees that the task run has successfully completed, it'll try and extract any artifacts that it recognizes from that task run. It'll generate signatures for that artifact, generate provenance, and then store those two things alongside the artifact in whatever storage backend you have configured. This could be an OCI registry or a GCS bucket. You can also configure various types of signing keys to actually sign these things with Tecton chains, including KMS keys, public private key pairs that you might have set up yourself, and full CO, which we had talked about earlier. So I'll do a quick demo of everything we just discussed with Tecton. So let me share my terminal. So in the interest of time, I've already created the cluster that I will be doing this demo on. It's an Amazon EKS cluster. And the most interesting thing about how I created this was I passed in this with OIDC flag. This is basically going to allow my Kubernetes service account to authenticate to full CO and request code signing certificate for the piece of software I'm about to build. So I already have Tecton pipelines installed in this cluster. Installing chains to add in supply chain security, the supply chain security manager is just a simple COOP control apply command. I've already run this, so I won't run it again. But the last piece of configuration we need to do is tell Tecton chains exactly how we want to generate our provenance and sign it. So there are four commands here. The first one is telling chains that we want the format of our provenance to be the in-todo format, which is what's recommended by the salsa framework. We want to store our signatures in an OCI registry, and we've also enabled the transparency log, which means we want to store our signature and certificate bundle in the record transparency log. We've enabled signing with full CO, so we don't actually have to set up our own public private key pair or point to KMS. We'll just request a certificate, and that's how we're planning on signing our artifact. So let's take a look at the artifact we're actually going to build. We're going to be using Kanako to build an OCI image and push it to a registry. So this is the task that we plan on running. There's just a few parameters passed in, including the name of the image we want to build, a few results here, which is how we're going to tell Tecton chains that an artifact was built. The first result is the digest of the image we're going to be building, and then we have the URL or the name of the image that we're going to be building. There are three steps in this task. So the first one basically just creates a simple little docker file, which we want to build. The second one actually does the build and push of the container image, and the last one writes the name of the image to our result so that we know what image was built. So we can apply this task to our cluster, taking a second. Amazing. And we can kick it off with the TKN CLI tool. So while this runs, I basically passed in and I've already stored this image name as an environment variable, or I have not. Let's show this again. I'm going to delete this task run that I just created. Let's start over. This is the image that we want to build, and let's kick off another task run. So now we're passing in the image name that we want to build, and we're running it under the service account I created earlier called ECR pusher, which has permission to push to my ECR registry. We take a look at the logs for this image. We can see that we're running through the steps, adding the docker file, building and pushing the image, and we have written the results. So this task run has completed successfully. If we take a look at the task run using that same CLI tool that Tecton provides, you can get a little bit more information about the image that was built. So we have the image URL, which I'll just store into an environment variable, and the digest. So we should now be able to run this image. It'll pull it down, and we can see that it has printed out Hello World, which is exactly what we expected. But now we want to make sure that the image that we built was signed and that provenance was correctly generated. How do we do this? The nice thing is that under the hood, Tecton chains has already realized that an artifact was built, attempted to sign it, generated signed provenance, and stored it in our OCI registry. As an end user, it's really easy to verify that this happened using the cosine tool. So at the moment, transparency, log, and full state of support are experimental in cosine. So I have to set this experimental flag. But all we have to do is a simple cosine verify, and then the name of the image, and we should see that verification is successful. If we pipe this into JQ, we can get a little bit more information around the certificate and the signature. And you can see that the subject in the certificate is the service account that we were running under, and that the issuer points to my EKS cluster that we ran in. So it's really cool. We didn't have to worry about keys. We didn't have to do anything. Everything just happened under the hood, because we already installed Tecton chains. We can also take a look at any provenance that was generated with the cosine verify attestation command. And looks like it was successful. Again, we see our certificate subject, our certificate issuer URL, and we can take a look at the provenance that was generated by decoding it and piping it into JQ. And you can see that we have our provenance now in the salsa provenance format. The subject is the image that we just built, and you can see that all the steps that we ran exist in this provenance. So we know exactly how it was built, and also when it was built. Let's transition back to the slides. Cool. So you can see that by just by adding Tecton chains into our existing Tecton deployment, we were able to achieve salsa too. Assuming your code is already in version control, our builds are scripted in Tecton. This build service is Tecton. Provenance is available, authenticated, and service generated, since it's been generated by Tecton chains. So Tecton plus Tecton chains equals salsa level two. Yes. So now let's talk about GitHub workflows and GitHub actions. So many projects are natively developed on GitHub. So it would be great if we could also generate salsa provenance on GitHub. And this is the motivation behind this presentation. So on GitHub, the standard technology that you use to run CI are GitHub workflows and GitHub actions. Whether you want to run simple unit tests or end-to-end integration tests, or maybe release pipeline, you can do all this using GitHub workflows and actions. Typically, you define GitHub workflows by creating a file under .github slash workflows on your repository. GitHub workflows are very powerful, and you can run arbitrary commands. You can also define so-called triggers to start your run. For example, you can start to run on an incoming pull request, or when there's a new push to a branch, or when a new tag is created on your repository. And here's a simple example of a hello world GitHub workflow. All it does is print hello world every time there's a push to the main branch. One powerful feature of GitHub workflows is the ability to support isolation between jobs. So you can define different jobs in the same workflow. Here we have two jobs, one in red and one in green called PR and secrets. Even though they're defining the same workflow, those jobs run in isolation. In red, we have a job that runs on incoming pull requests. The pull request may contain malicious code, might not have been reviewed, so we want it to be isolated from other jobs in the workflow. And in green, we have a sensitive job that accesses credentials or other sensitive information like a secret. This could be the job that publishes container images to your registry and needs a secret to log in the registry. So what I'm presenting today, using GitHub actions and GitHub workflows meets the salsa level three requirements. So let me tell you a little bit more about what those requirements are. The first requirement is that the build must use an ephemeral environment. The motivation behind this is that it makes it harder for an attacker to gain consistency to your release pipeline if they were to gain, if they were to attack it. On GitHub, each job in a workflow runs in a fresh VM, so we get that requirement for free. A second requirement is isolation, meaning that the provenance generation must be isolated from the maintainers. So what this means is that the maintainers that are building an artifact shouldn't be able to interfere with the provenance generation. And this leads us to the last requirement, which is that the provenance should be non-forgeable, meaning that maintainers shouldn't be able to lie or temper with the provenance information. They shouldn't be able to lie about what source code was used, for example, to build the artifact. So let's see how we can generate salsa three provenance on GitHub using an example. All you have to do as a user is define a workflow and pull the trusted builder. Once the run is triggered, the execution is handed over to the trusted builder here on the right. The trusted builder is hosted in a different repository. In our example, it's called github.com slash trusted slash builder. And the trusted builder is not under the control of the original workflow on the left, and therefore the workflow on the left cannot temper with the execution of the trusted builder. So we can do anything we want in the trusted builder. And the first step we take is building and publishing a container using code. And then in a second step, we can generate the provenance, sign it, and upload it to a registry. And here, we can just use cosine API and the six-store tooling to do that. So something I want to point out is how signature generation happens. I think Pri already talked about this, but I want to mention it again. In the example that you saw, we didn't have to provide any sign-in keys. And this is a key feature of generating source of provenance using six-store. Key generation and management happens transparently through workflow identity. So when the trusted builder runs, it is provisioned with a unique X509 certificate that uniquely identifies it. And for this, we use OIDC, as Priya mentioned earlier. This certificate is then used to sign the provenance. So during provenance signature verification, we can inspect the certificate and learn who produced the build. Just to make things even clearer, I want to compare the WebPKI and the SalsaPKI that we've built using six-store. On the web, a CA may be verisign. And when you visit a Google website, the X509 certificate that you get during the TLS handshake will have the Google identity, such as 3w.google.com. In the SalsaPKI with six-store, the CA is six-store. And when you verify the provenance, the certificate contains the identity of the builder. So during verification, we can inspect the certificate and identify the builder by name. And if we trust the builder, then we can trust the sun provenance and its content. So it's pretty easy to verify provenance. We've built a tool called SalsaVerifier that can help you do that. And under the hood, it's using the cosine API. All you have to do is pass it an artifact OCI of your container and tag. And one option that is mandatory for you to pass is the source code that you expect this container to have been built from. In our example here, it should come from github.com slash origin slash repo. Optionally, you can also pass a branch, which by default is set to main. And then you can also pass a tag if you expect the container to be built from a particular version or tag of the repository. So as Priya mentioned before, thanks to six-store, we don't have to handle public keys. And you can just pass the identity of the repository you believe the container should come from. And the verification happens automatically for you. Okay, so let's have a quick demo. Let me share my screen. So the example we're going to take is hosted on github. It's called KubeCon minus EU22. It's a simple hello world, which will print a random UID. So we're going to take this go file and package it up as a container using code. Doing this is pretty easy. As a user, what you have to do is define a workflow, a github workflow. Here it's called code minus publish. And then here we define different jobs. You can ignore this part. You can look at it if you're interested, but the most interesting part of this workflow is this part here, the build part. All we do here is we basically call a trusted builder, which is hosted under this repository.  So here we're saying build a multi-architecture image and tag the container with tag five and tag six. We also pass environment variable that coexpects such as code docker repo, which is just the docker account where we want to publish the resulting container image. And we pass a password to be able to publish to the registry. Then all we have to do is run this workflow. So you can go to the action tab here on github and here on the right, run workflow, and we run the workflow. So it's going to take a few minutes for this to complete. So I've already run the release a few times. To save up sometimes. And here on the left, you can see all the different steps that were taken by the builder to build this image and publish it and sign the provenance. And this is the resulting container image that we've got. So let's try to verify the provenance. Okay, so let's first verify that we can run our container image. Okay, so this seems to be working. We have our hello world. We can also run it by using the hash, which is the same thing. Okay, so at least our container image is working. Now let's verify the provenance. Okay, so sasa provenance was verified and docker, the docker container is printed. That's what it resolved to these tactics. Now let's take this command and change the expected source repository. Let's say 23. And as expected, it doesn't pass the verification because the source repository doesn't match. As we said earlier, we can also pass it a main branch which verifies. And if we were to pass a different branch, it would fail. We can also print the provenance. And as expected here, it looks very similar to what Priya presented with tecton. Here we get the source origin repository and the commit hash that was built from. We also see a list of environment variables that were passed to Co to build. And also the command that was used by Co to build the container. There's additional information about the environment used by the trusted builder. Architecture was AMD64 running on an Ubuntu machine. And we see that the trigger event was a workflow dispatch, which is just saying that I clicked on the button to run the workflow. We also see up here that the reference is the main branch of the original repository. So we have all the information that we need. So let's quickly go back to the action run. It just completed. And we can see again that this build is reproducible. And we get the same container image that we verified. Awesome. That was super cool. Let me present it again. Yeah. So to conclude, GitHub Actions and GitHub Workflows gives you Salsa Level 3 if you use a trusted builder. Thank you, everyone, for attending. If you have any questions about this talk, feel free to reach out to either of us. I'll be there in person. So look out for me. And yeah, thank you so much for attending. Thanks, everyone.


Moving on to our next subcategory which is best innovation in mobile marketing may I invite on stage Mr. Fawzan Rahim co-founder cheetah mobile and Mr. Yashudas managing director and co-founder trigger bridge who was also part of our online in online screening council Mr. Yashudas and Mr. Fawzan Rahim okay again silence of the lambs what is this other who does not working I think the spirit is not working no spirit this is ridiculous yeah guys please I'm requesting I'm pleading all right let's move on to the shortlisted nominees in this subcategory the jury also looked at innovations in mobile marketing I think we've got some way to go in terms of really understanding which tools to use how to deploy those tools at scale and how to combine really cutting-edge consumer insights in a way that digital can powerfully communicate a message to a desired target audience we did find a couple of brands doing it extremely well but I think the jury looks forward to some more exciting stuff in the coming years in terms of marketing to consumers in a digital world BHD gets another medal for lack may make up grow I have a joint medal winner in this subcategory let's find out who the next bronze medal winner is more medal to be given away in this subcategory let's find out who the winner is a four kinder joy story station