em running so to at least be aware of what infrastructure you have running what API's are running are sort of being allowing connections to your application many organizations will maintain an API hosts inventory so let's make sure that we understand a distinction between an API contract and an API hosts inventory so that the contract is defined by documentation it's often created through open API spec and it describes how to interact with a specific application or service on the other hand an API hosts inventory will encompass all of the API contracts that are under the scope of the team responsible for the the API's maintenance so properly managing new releases also falls under the scope of assets management you should always set up distinct environments for dev tests staging and production and you shouldn't use production data in pre-prod environments aside from just being like a risk for additional data breaches it exposes your internal users data to your teams and that may also be a violation of of GDPR whatever California and equivalent there is so improper assets management this is often mitigated through operational controls so you should categorize your public API's and APIs that are meant for internal or private use make sure that your APIs that can interact with PII is tagged as such and so is given special treatments and if you have a a deep understanding of the data flows and the connection between the services that comprise your infrastructure then there's a much better chance that you'll be a step ahead of you know attackers attempts to exploit your assets so unsafe consumption of of API's that's the last one and also a new one to 2023 so we're clear that user inputs into your application are vulnerable to exploits so what about third-party service inputs so devs tend to trust and understandably so other companies API is more than their own users inputs into their their applications the conclusion of this is that the devs are more likely to adopt weaker security standards for input validation and sanitization when it connects to third-party services versus just user inputs so there's a lot of different exploits that can be achieved through this vulnerability anything from data exfiltration remote code execution denial of service can be done through a yeah a compromise integration to a third-party API so the message here I hope I'm clear you should apply the zero trust security model to integrations as much as you do for for user inputs so imagine for example what will happen if Twilio or Stripe were breached there's a lot of companies that depend on those services and all of their downstream integrations would potentially be able to be exploited through those those breaches so this is my last slide I'm going to actually repeat this talk in a few minutes if you guys if some of you arrived late we're looking essentially to partner with organizations that are building API reliance and modern web applications and yeah we'd love to to to sort of get in touch if you if you guys have any specific struggles or concerns we've we've built open source API security libraries we've love to share we'd love to to sort of get your feedback on and and see how it could be of use to you guys so just yeah come speak to me email me if you want the slides just as a reminder of what we we've covered and yeah thank you for for coming here I don't know if there are any questions so here we're not talking about like what's what sneak does about like packages right sort of checking that the packages that you're included in the libraries that you're including in your in your application are we're not talking about stuff like what what sneak does I'm talking more about integrations to for example Twilio or Stripe where your application is expecting some and you're doing a validation to make sure that what's coming into your application is is what's what's expected but if you're not doing that step of sanitization and and validation then you are at risk of being breached through that that that surface now I guess this is where we sort of have to in some ways hope that the organizations that we're depending on for services are also applying best practices with when it comes to their API is that they're also enforcing an API contract that is very clear to you as a developer that's integrating with the the service and yeah just don't implicitly trust that because it's a brand name that they're doing things correctly you should have the steps in place to make sure that what's coming into your infrastructure isn't going to affect it negatively it's a funny one this this one this unsafe consumption of of APIs there's actually like a little bit of a debate right now in the OAS community about whether actually this one should be included and the main argument for its inclusion is the fact that there's less just awareness of this being a vulnerability versus just inputs from users inputs from users definitely I'm pretty sure every developer knows that there's many vulnerabilities that come through that but inputs from third parties not as much it's part of the API economy I guess which is like a growing thing yeah well I worked for firetail I would say that's one we have some open source components which is why I'm sort of allowed to talk about it during this this sort of during scale 20x so that's that's definitely one I'll open the room if anybody has any other suggestions for I'm not sure there was another question in the in the back yeah oh okay yeah I'm glad that we've moved on from all the violence from the industrial revolution we can laugh about these sort of breaches that don't have any sort of you know violence associated to it yeah that's great example I love it yeah segmentation definitely an importance an important principle so I don't know it was everybody in the room present when I started the presentation because I was considering sort of just redoing it since this was like a 30 minute presentation I have time to do it another time but if I hear everybody was already present then I don't know if it was actually worth it I can brush through it if if you guys want we'll have like a 20 minutes to to go over it yeah may as well all right so yeah the subject of today's presentation top API security risks the OWASP API top 10 in a nutshell so a little bit about me graduated from the University of Montreal I was born and raised in Montreal then worked for the the fourth intelligence company Canadian forces reserves units and then moved on to sort of startups digital innovation worked in cloud security and then I have some interesting hobbies as well or at least I find them interesting so before we actually get into the subject of API security let's talk about what came before the sort of threats that happens in the industrial revolution so what we had back then were things like high women or stagecoach bandits that would sort of accost you as you were traveling city to city and would unfortunately try to steal your stuff or sometimes even worse beyond that you also had high seas pirates the US first overseas conflict was actually with the some barbie coast parrots in modern day Libya it was not a conflict that went particularly well for the US at that time this is long time ago early 1800s and then of course nation states had many many world wars more than just the two of the 20th century even before that but yeah we've we're no longer just in the industrial revolution now we've moved on to the digital revolution so what sort of threats do we have nowadays well you can get some physical tax directly on a physical data infrastructure so think an aws data center for example can be can be attacked you can have digital disruption to your to your operations so think of the breach or the the effects that happens on during the in 2010 one on the Texas power grid where a company that was managing the supply chain for oil suffered a ransomware attack and essentially you had some very long lines at gas stations you had some very high gas prices as well nothing good third you can have some IP thefts or actual asset theft I think IP theft that's generally understood someone steals your code base and then just understand what you've been working on asset thefts think for example NASA sending a satellite to space and then the only control system for that satellites being taken over by some malicious group could be more than just satellites could be drones could be rovers anything that's remotely controlled essentially and then finally PII data in exfiltration so yeah there's some real reputational and monetary loss that can that can happen off the back of PII data theft so how did we actually get here so we've established that today the threats to industry are different than what they were previously they're consistently changing so five or six years ago I was helping organizations safely get migrated to the the cloud I saw all kinds of cloud infrastructure issues so the issues are not the same that as what happens today best practice changes and today what we're seeing is that APIs are becoming much more of an important source of vulnerabilities to the two organizations running IT infrastructure so this brings us to the subjects of today's presentation application programming interfaces and the OAS API top 10 the release candidates of actually 13 February 2023 so very recent stuff less than a month old this version of the the top 10 so number one broken object level authorization so if you weren't here the first time I gave us this talk the first to this broken object level authorization and the next one broken authentication this represents the vast majority of breaches so 70 plus percent of of breaches according to our research at at FireTail looking at the past 10 years of publicly disclosed breaches so for this one broken object level authorization devs will just often incorrectly assume that authentication equals authorization that's not the case they're going to assume that an API call will only be coming from known good client software like a mobile app and that's going to help them control the parameters of API requests which will then make it impossible for user A to request user B's data unfortunately that's not how reality works any sort of predictable pattern in an applications data structure can be exploited by a malicious user so if you're not using random and unpredictable values to identify your data objects then they can be protected and so are much easier to exploit so let's use a right share app example say malicious user guests your right share accounts user ID because they figured out that those IDs were sequential for example 101 102 103 that attacker could then mock a legitimate API call to fetch information about that user's right history the legitimate user's right history so that's that's a sensitive information at PII data breach so essentially this unauthorized user gain access to a data object that they should not have had access to so if the right share apps backends doesn't check that this user this malicious user is allowed to access that the specific data object in question then of course the API is is vulnerable so the mock request made by our malicious user it's only going to go through if that mock API call is not properly checked for authorization if the user making the mock request actually receives the right history that they're requested that's a breach the authorization check was not made by the application logic and object level authorization of course has been broken so if I haven't been clear this is really really bad this is the sort of security breach that security professionals lose their jobs over user A getting user B's data is really really terrible it's yeah it's worse than sort of marketing data breach where emails and first names get released it's much worse than that so yeah it's it's a really good idea to use unique user identifiers or globally unique identifiers to mitigate this risk and ensure that all functions actually check for authorization number two and again these first two by far the most importance of this top 10 list this one is about user impersonation can a malicious user trick your application into believing that there's someone else so there's a few common ways that this can happen credential stuffing that's one of them is that's using a pre-made list of user names and password and trying every single one of them out until one of them works another one is using brute force attacks against a specific user where an attacker tries out different passwords or MFA tokens until the they find the right one and take over the the count that they're looking to take over third think of a poor in transit security like lack of encryption or just poor or no hashing putting off tokens or passwords in your URL this can make your users very vulnerable to to attack so malicious users can then are then able to intercept those authentication details by sniffing the network and then this would lead to a man in the middle attack fourth tokens or other credentials that are properly generated by the front ends but then never actually checked for validity by the back end so your front end here is doing everything right it's your back end that's not using what the front end is giving them and checking that the authentication is legitimate and then finally exploitation of deep links or other one-click authentication mechanisms that aren't some properly secured so to summarize broken authentication is essentially a malicious actor gaining access to a real user's rideshare accounts and then ordering for themselves as many rides and as much food delivery as they can get away with so some best practices to implement to limit your app's risk here use minimum password lengths rate limits API calls don't rely on long-lived credentials and implement CAPTCHA or other RU human tests to your authentication services so an easy example of a breach here happens late last year so not very long ago Optus this is an Australian telecommunications company they were affected by a breach because network configuration change exposed a previously 100% internal API and this API well didn't check for authentication so security through obscurity it's it's not good enough implements authentication everywhere yeah again these first two by far the most important of the top 10 moving on so broken object level authorization again let's use the right here example marketing team had a great idea they want to show the world how diverse the right here apps user demographics are so they're having the public website show a rotating feed of user first names and the city that they're from so it's fine right it's nothing too crazy they really only need the first names and the cities for the website that's not personally identifiable information unfortunately the back in service that they're using to to power this this new website feature is gives them the full user objects that returns it to the the public website well it's just easier to develop that way right it's easier to just get all the data and then cherry pick the few fields that you need to do with your to build your feature unfortunately all the extra data is actually still there it's just a few clicks away for someone with very basic technical knowledge and unfortunately for our example right here company the extra user data contains some pretty sensitive info like a new field for bookmark addresses and suddenly it's not just a funny addition to the website it's a user data breach so what could have been done to prevent this a couple things you should handle data sanitization on the server side only return what's actually needed you've heard the expression need to know well since the website doesn't need to know about user PII just don't send it back cut it out before it gets included in your API response and also you should maintain an API contract and you should make sure that it's being enforced so contract should have stated that user bookmarks are for very specific scenarios that don't include the public website with this in place it yeah that's uh that PI would not have been sent back to the the public website so fourth unrestricted resource consumption if your API is being hit by so many calls that your servers are made unavailable you've probably done something wrong with the design of your your API it can lead to denial service attacks which make the news very frequently activist collectors they love this technique it's very visible can make a very big PR splash doesn't look very good for the the organization suffering this so if a request can make a call for an unlimited number of records from your database and your server actually tries to fulfill that's a request it's going to affect the performance of the database and all the services that actually depends on that on that database so furthermore if a malicious user can send your server a two terabytes jpeg a jpeg as their profile picture and your server doesn't handle that gracefully it's going to have an effect on the service ability for other users so this is where rate limiting pagination and a transparent API contract come in so rate limiting that's going to prevent users from sending requests at a rate that is too quick for your back end to handle pagination will also allow users to slow down their access to your databases by returning a different set of results with each request so I think items one through 99 items 100 through 100 and 99 and so on and so forth so a clear API contract here will mean that users including the team responsible for handling the client side are aware of the limitations of your API and at the very least pagination and rate limiting will minimize the scale of a breach so it's difficult to be completely safe from a denial of service attacks even more so distributed denial of service attacks hackers can very easily like change their IPs change their device IDs and yeah it just makes it very difficult for you to differentiate between what's a legitimate request and what's a fake one so for now suffice to say the more visibility that you have on incoming requests the more will be possible for you to to catch the ones that are intending you harm fifth each API call that's being made to a server is received and processed by a specific function in the application so before executing the code the functions that evaluate the metadata that was passed along with the API request this data is going to include things like who made the request what type of request was made and where the request should go so a user let's go back to the the right share example very easy one a user who requests a ride should be the only one that should be able to interact with the function that handles payment processing for their accounts the driver who gives them a ride that's a different user in the application should not have the ability to mock the user API call to the same payment processing function and change how much they're being paid for the fare you can very easily see how this would be beneficial for the driver but not very good for the person paying for the ride and for the the organization managing the application if you're not using the principle of least privilege here to define a limited scope of user allowed actions then you'll be vulnerable to broken function level authorization so to avoid this you should use very granular access control to define who is allowed to do what in your application so as a writer I can modify how much I leave as a tip for a ride that I've taken as a driver I can review how much was left for me as a tip for a ride that I've given so unfortunately it's it's like a lot easier to write an application that treats all users the same without making the distinction between modify or view yeah 6th server side requests forgery so this is where this is actually a new one to 2023 this is where the vulnerability allows attackers lateral movements from a public facing server to internal only resources so this can lead to data exfiltration if the server can be forced to interact with third-party resources so you should make sure that your network topography meaning how you set up your network architecture you should make sure that it doesn't let the servers that you use to fetch external resources then also interact with internal only resources so be very explicit about what sort of URL structures and which ports should be used by external services and if you can it's a really good idea to use a white list or a list of allowed IP addresses or DNSs so as always validate and sanitize all input data before it reaches your data layer but also checks outputs before they're set back to clients so this one security misconfiguration that's a large category right it'll include things that pertain directly to the API and its infrastructure but also things that are higher up in the application tech stack but also further down in the infrastructure stack so these misconfigures are often going to be part of vulnerability chains where essentially the idea is to link together multiple exploits in a row to gain access to like a better exploits of the infrastructure so for organizations that maintain APIs like just one vulnerability probably won't cause a catastrophic breach but usually if you find if a security researcher or hacker finds one they're probably going to find more than one and if they can chain more than one together then that can lead to a much higher impact breach so in a writer example let's give a simple two-step vulnerability chain example that allows for account takeovers so the first vulnerability in this in this chain will be that in the login process specifically logins through Facebook a faulty implementation of the login mechanism means that the rideshare app's off step can be injected with the Facebook ID of an account controlled by an attacker so this would this Facebook ID would replace the ID of the legitimate user so this would allow the attacker to bypass the Facebook login step so the next step would be passing the multi-factor authentication step so here unfortunately in our app example rate living was never actually implemented on this endpoints checking for the 2FA code meaning that the attacker can use a script to try every single possible combination of the six-digit verification code and yeah that allows them to pass through the MFA step and so those two vulnerabilities sequentially leads to a full account takeover each one individually probably fine you won't actually gain access to to anything but both together lead to bad things so let's go back specifically in what terms of misconfigurations can can happen so insecure transport protocols TLS version 1.3 is the latest it was released in 2018 it's the one that you should use use HTTP methods you should only allow the use of HTTP methods that are necessary for your application there's a lot more than you think just don't allow them for your endpoints third require the latest HTTP security headers so HSTS content security policy x-frame options these are HTTP security headers that are good to use nowadays these are still best practice fourth overly descriptive error messages so Windows is notorious for this so to give an example of a breach that was caused by this this starbucks.net server it was an important link in a vulnerability chain that led to PI breach that was reported by a security researcher fortunately not by an actual hacker but still a bad breach for for starbucks here so yeah make sure that your endpoints return error messages that don't expose anything about your application's logic be very generic short still give some information about what can be done to fix the request that was sent to your your endpoint but don't expose anything about the underlying logic fifth use the HTTPS I know very basic stuff but still we see API is not enforced the use of HTTPS so yeah good to use and sixth enforce a cross origin resource sharing policy a chorus policy that restricts data flows to only pages or domains which should communicate to each other and then finally everything related to your infrastructure misconfigurations just follow the security pillar of the architect framework that'll go a long way in making sure that the infrastructure power in your API is is not going to be what leads you to a faulty or vulnerable API eighth so lack of protection from automated threats also a new one to 2023 so Ticketmaster was famously recently affected by this during the the sale of Taylor Swift concert tickets malicious users were able to exploit the API is from Ticketmaster to get every single ticket for the Taylor Swift concerts at what turned out to be very cheap rates compared to what they were then able to sell them for so it was all over the press it was called a fiasco there was a senate investigation was a whole thing you guys have also all been affected by sort of spam comments on LinkedIn Facebook Instagram yeah these happen all the time the point here of those those examples is that attackers are going to use very normal user flows within your application but they're going to do it in an exploitative manner which makes the experience worse for everybody else so our our lab at Faratel we've shown that's actually 90% of requests to APIs will be bots that are going to be scraping for secrets so things like .end files git.config graph query or admin endpoints yeah bots are going to be looking for those to exploit it so to mitigate this sort of thing OWASP recommends using mechanisms like device finger printing or user flow analysis to identify and block automated threats so sometimes when I'm googling stuff at a frantic pace I get redirected to a capture before I can reach my results that's the sort of mitigation strategy that isn't too obstructive to normal users but would most likely vastly reduce the impact of automated threats nine improper assets management so API is routinely used versioning to account for the sometimes conflicting priorities between development velocity and support for legacy systems so despite releasing a version two of your API you may want to give a grace period to the legacy users of your API using version one so that they have time to update how their applications work with your latest version so in theory this would be fine however in practice and given real life time constraints development teams will make the decision to just implement the latest security best practices on the latest version of the API and just forget about updating the previous version so you should at least be aware of what you're running in terms of of API is what's what's online you know if you have zombie APIs in your your stack at least be aware that they're there you shouldn't be running them at all but if you are well you know it's good to have visibility and then to make this even more professional you should run you should maintain an API host inventory so what's an API host inventory well it's it's different to an API contract the contract is much more at a tactical level it's it's defined by documentation often created through open API spec and it describes how you can interact with a specific application or service the host inventory will encompass all of the API contracts it's much more at a strategic level and yeah will enable security teams to sort of have a better visibility over the their scope of responsibility so properly managing your releases also falls under the scope of this of this category you should always set up distinct environments for dev, test, staging production don't use prod data in pre-prod environments to test not only are you creating a risk for potential data breaches but also it exposes your internal teams to sensitive customer data and that in and of itself might be a breach of GDPR or other local regulations so how to mitigate this it's usually through operational controls I mentioned the API host inventory but you should also categorize your public APIs and make them different to what APIs that are meant for internal or private use so ensure that your APIs can interact with the APIs that can interact with personally identifiable information are tagged as such so at least you can take a better look at them than the rest of your your stack so as long as you maintain a really good understanding of the data flows and the connection between the services in your stack there's a better chance that you'll be able to yeah be one step ahead of of attackers so last one I know we're going a little bit over time this is our second run through thank you for for being here for both and again it's new to 2023 so we're clear that user inputs into your application are vulnerable to to exploitation but what about third party service inputs so unfortunately devs tend to trust and understandably so other companies APIs more than they trust their own users inputs into their their applications so the the conclusion of that is that the devs are more likely to adopt to weaker security standards for input validation when it comes to those third party service inputs so there's a lot of different exploits that can be achieved through this vulnerability think data in here exfiltration remote code execution denial of service and yeah all of this can be done through a a compromise integration through a to a third party API so the message here to be clear you should apply the zero trust security model to integrations as much as you do for for user inputs treat them the same it's not because it comes from a trustworthy company that's what's going to happen is meant to be trusted so to give an example here imagine what would happen if Twilio or Stripe very commonly surfaces were breached and then all the downstream integrations to their APIs were exploded through that breach not a good situation for anyone involved in those scenarios so my call to action today well first thank you for for coming we're looking to partner with organizations that are building APIs and on AWS ideally and we just essentially want to learn about their their problems concerns their complaints what their life's about and yeah we've at Firetail we've built some open source API security libraries that we'd love to share with you love to get your feedback on so yeah just come speak to me if you want the slides just email me I'll be happy to send them to you so yeah that was it thank you any questions I'll take that to mean that everything was clear so yeah thank you for coming these two reviews about how to breach happen because they don't want to inspire copycats but yeah it's it's a very growing source of vulnerability in regions with GI and on it it's um if you're at all aware of what's happening with uh X3 buttons they have sure yeah they listen that was like super obvious stuff that was happening like five six years ago right so like Amazon put a ton of effort and all the other copyrighted with a ton of effort into making sure that um like they're in their data and their story services were were secured and they're easy to secure to them and if you guys unfortunately there's no major vendor behind us right everybody does differently in the work then yeah so but like the conclusion if you keep in mind that you're doing authentication and authorization of operating you're you're covering 80% of of it's just lack of awareness right they just don't know that this feature is there that they left itself no why are some lack of awareness they skeed of their it's like going interchange with their complex path we're not going to start from they skeed they haven't been asked to do it so they don't need it and and no customers ever ask to do it keeps you employed right so centralize half work management system and put a complex path along the list type clicks or well I don't want to mention the name I don't do I'm in a large city right now but I'm ready to have enough yes and they don't want me to attack them because they're ancient and they'll follow us right yeah growing problem I'm crobe I'm the director of security oh yep yep hi everyone great hi everyone how do you trust open-source software I'm Navin Chini Vassen it's just a little bit about me um I'm happy to be here to talk at scale this year I am all about supply to insecurity and open-source software I am a maintainer and a contributor for a few projects in OpenSSF I'm a member and a contributor at six store and I'm contributor to Salsa code base all these three are get up organizations focusing on supply to insecurity and I've been actively contributing open source for a few years which helped me get Google peer bonus award in 2021 and 2022 right now I'm an independent developer looking for ways to contribute onto new projects and and if you want to check out my profile if you if you can check out my get a profile to see what I'm doing and if you want to talk to me anything about supply to insecurity open-source software you can hit me up in Twitter great welcome everyone my name is Brian Russell I'm a product manager on Google's open-source security team work a lot with the OpenSSF and I in particular work a lot with OpenSSF scorecards so before we really get into what the scorecard is let's talk about the problem that we're facing so we've got this blocky looking diagram here and we can think of it as basically what modern digital infrastructure looks like oftentimes when you pull back the cover and take a look at what's running underneath any system you've got a whole bunch of different pieces there they come in different shapes and sizes and no some of them are very important some of them are more precarious than others but what you have is is a real mix of different things and you don't have a lot of insight into what's actually going on in terms of making these blocks in the first place you might know how important they are to your system but understanding how they're developed how that community operates that part is usually pretty opaque to a lot of a lot of people so that begs the question what if we did have some insight into what's going on in this infrastructure and that's really what scorecards is wanting to help start being able to help people see so if you have these scores you have all of a sudden a sense of which projects are doing really well in terms of embracing best practices in developing software securely which projects you know could use a little bit of help could be doing a little bit better and then which projects are actually doing really quite bad they don't really think about security when they're developing and those are the projects that you know you would want to concentrate on if you're using them or if you're bringing them into your own open source project as a dependency it's important to direct your attention kind of where it's needed most so here's what a scorecard looks like there are a few ways to generate it to pull this data this is coming from a service that you know shameless plug from the google side it's made by this site called depths.dev it lets you go in and see for any open source dependency what do those dependency trees look like it also provides scorecards though and it's a nice UI experience if you're just wanting to look up a scorecard for a particular project we'll get into a little bit more how those scores are generated and how we would source them but in a nutshell the scorecard project right now is running effectively a cron job that every week is scanning the top million and a half projects as computed by a sort of criticality score how important they are in the rest of open source so I feel free to follow along on this next part if you want to take a look at a scorecard you can pull it up on your phone you can either use a qr code or just go to depths.dev and you can think about a project that you already know about or maybe one that you're helping to maintain any project that is within kind of that top million and a half should have a scorecard associated with it if you just want to find a project you can always just look up scorecard directly you should see a sequence of screens something like this I'll say it's always a little bit better on the laptop but I made the screenshots with a phone in mind so if you go type in scorecard look for the specific little project folder that's associated with it you can scroll down the page a little bit and you can start to see a scorecard so we're back to this list of checks and now let's talk a little bit about what these actually are so in a nutshell you know we are looking for what are generally considered best practices when it comes to developing and managing a project securely and each check is composed of a name that you're seeing here a score and then some underlying logic that goes out and actually looks for evidence to compute that score so I'll go into a few just checks I thought about going through the whole list but it seemed like let's start with the top five and and just kind of go from there so if we look at our first check that's on the list we've got code review and in this case it's looking for does this project require that someone else reviews code before it's merged in and each check is composed of a risk level as well and so they range from critical to high medium down to low and in this code review sense you know there's some caveats here we certainly recognize that there are single maintainer projects where code review is not going to be feasible but it's it's basically you know one kind of piece of evidence and one component of whether or not your project is is basically building a community that's looking at things together if it's looking to develop things securely so I'll go through you know four or so other ones just to to give you an idea of what each is I should mention too that for each of these checks the way that Scorecard works it's calling the GitHub API right now we're working to expand that past GitHub to some other places but these aren't kind of self-certified pieces of evidence all of this is just gathered programmatically checking for things that that you could check just as a general user coming to GitHub so if we just go to the next check down we look at maintenance is this project still actively under development you know for pretty much any project that is inactive development there's going to be some activity that happens on it so we look across a 90-day window whether or not things are being done if updates are being made we would expect to you know if dependencies need to be updated within a project all of those things should be happening and so we consider maintenance one of these checks that Scorecard's looking at if we jump a little bit down we want to make sure that you know just permissions to actually change the repo or configured in a way that it's read only we each of these checks has specific descriptions of how they're implemented so you can see whether or not they would pass but when it comes to token permissions we're really just looking at who has access and whether or not they have more access than then really they should we also look for dangerous workflows there's different patterns such that you know if you have your project configured in a way let's say that it kicks off some CI when a pull request is opened and someone can basically insert their own sort of script to run that that would be considered a dangerous workflow so there's a few different patterns that we're looking for when we run this particular check and then the last one that I'll just highlight here is binary artifacts this plays very much in open source mentality where you know we want there to always be the actual source code and not some compiled code that we can't understand so there's a few exceptions where you know different specific frameworks require binaries as part of of how they develop software but we're looking for anything past those and we're trying to make sure that overall you were just storing source code in the repo itself so different questions kind of come up where we're trying to get better over time of kind of explaining you know can I use scorecards if if you have a private repo the answer is yes you can use scorecards on that you can run a cli tool against your repo you can set it up in a github action but you can run this privately it doesn't have to be a public repo let's say that you use get but you do not use github the answer is yes but there's some limitations specifically anything that's tied to the github API that would require the project to be in github but we can check for a number of things that are independent of where you store your get repo and then if you're using gitlab the answer is soon this is something that is currently under development and something that we're planning to be pulling in in the next few say months at this point so that's that's generally what a scorecard looks like that's how checks work we've seen a few different examples of what checks are sorry you have a question so you're saying in terms of like for depths.dev we'll get to that but the short answer is is you can install the github actions action that will automatically score the project and it will automatically push that score to depths.dev it's a good question we also have a few minutes purposefully left at the end of the presentation so if you have more questions we'll definitely have time to talk about them further so i wanted to talk about here just what is this general state of supply chain security that we're in right now like exactly why are we talking about scorecards what is what is kind of the bigger landscape that this is this is operating in well to start with open source software demand is is always increasing in the links foundation published in a blog post that free and open source software constitutes something like 70 to 90 percent of modern software solutions and on top of that you know just that the downloads of open source dependencies has been growing by an estimated average of 33 percent across all of the ecosystems that they were looking at so we know that the demand is going to increase what we've also seen and this is from sonotype state of software supply chain reports which is free and and I highly recommend people take a look at if it's not on your radar now they looked at specifically what is happening with software supply chain attacks and they found that you know this this graph really tells the tale all by itself they're increasing a lot more and more you know people are are trying to find ways into any sort of system and often dependencies that are being pulled into the system and use they are are suddenly becoming one of the easier attack vectors to hit I think in part because some of the other good security best practices are getting followed more and more but that means the software supply chain suddenly becomes one of the more vulnerable pieces so what's this have to do with scorecards also in this sonotype report there's a specific section in which they started to look at what can you look at to really see if a project is is likely to have vulnerabilities over time like is there any sort of indicator that we can use to really see you know if this project has these certain things in place are they less likely to be vulnerable and what they found was that scorecards could be at least a decent predictor of whether or not vulnerabilities would show up over time vulnerabilities are reported at different times but a higher scorecard project or I'm sorry a project with a higher score usually indicated there was a lower probability of vulnerabilities actually being found and then in this report they also broke down which checks are more important than others you see that code review is is actually the highest one which intuitively makes sense if you have more people looking at code you have less likely of kind of making a mistake scorecards has had adoption and some notable mentions by various foundations they won't get into each one I'll highlight Eclipse just though off the bat like Eclipse is is basically using scorecards to take a look at projects within their foundation and using is really a good starting point of where they can invest in different software supply chain improvements and I think their example is is good for a lot of organizations where if this is a problem that you're starting to be concerned about like this is a good foothold to get you checking for some basic things to really see if some of the very basic pieces are covered so rather than and kind of give more examples we we asked one of our scorecard friends Christopher Robinson or CROBE as he sometimes goes by he's a director of security communications at Intel we said you know what do you think about scorecards and he sent us back this video that we thought we'd play for you I'm CROBE I'm the director of security communications at Intel I'm also a community leader and contributor to the OpenSSF I'm here today to talk about how my organization uses open source software and the OpenSSF scorecard Intel has been a long time contributor to the upstream open source community with over 20 years of involvement in a multitude of projects we're also one of the founding members of the OpenSSF we're extremely excited to see projects like the OpenSSF scorecard come into being because it not only helps us understand the security details about the open source software that we leverage in many of our products but also internally and it also helps us understand the security qualities of our own products right now Intel's making sure that all of our public GitHub repos are reporting out through the scorecard tool so that we can understand where we can improve but also so consumers of our software understand the types of things we're doing I think scorecard is an amazing project that has a ton of value to help describe the security posture of open source projects up and down throughout the ecosystem so I can endorse it strongly enough if someone's considering a way to evaluate open source software the scorecard is an excellent way to make that happen thank you all right thanks to CROBE for for sending that to us also if we before I hand this off to Naveen to do some demos and explain a few more things I did just want to say a note about what the OpenSSF really is I used it you know just in the actual name of scorecards but we wanted to talk about what this foundation is really seeking to do it's it was formed around three years ago at this point and it really is meant to be a place where different organizations who are very interested in trying to make open source software more secure for not just them but the whole world it's a place for them to come together to have conversations about how can you actually do that a place to really invest in different tooling and to just really try to raising the bar on making software more secure so it was formed by a few different organizations but that number continues to grow and I thought I'd say a note too on just you know how it works kind of under the hood if you look at this top diagram you can see this is the rough life cycle of source to production to the end consumer and the OpenSSF has divided up different working groups along this different process so they have things like best practice working groups where they're trying to just say at each part of the process what is going to help make things more secure they have working groups around vulnerability disclosures and doing that in the right way and in a way that you know basically minimizes the vulnerability impact different groups around tooling just other related projects in general all of these things if these are of interest to you there's a lot of ways to learn more about the OpenSSF there are email lists Slack groups there are public meetings there are recordings of those public meetings that you can go back and view they're active on social media you can follow them message them can use email directly they actually have a page where all of these different things are consolidated so it's just openssf.org slash get involved in all of those links are right there so that is kind of the intro so far to the problem that we're we're working on and in the organization that we're working within so I'll hand this over to Naveen to talk a little bit more about how else you can use the scorecard thanks Brian like Brian mentioned one of the ways there are multiple ways to utilize scorecard you can use scorecard's client get up action but last fall and this has been there for the other client has been out for almost a year and a half too and last fall we released a scorecard's API why did we release an API because we spoke to customers and and because we've been scanning this 1.2 million repositories which I'll get into all of this data is available for anyone to consume using BigQuery and it's been it's been doing the crown job it's been running every week and it's been doing it for the past one year so there's phenomenal amount of data available but the biggest problem we realized is people like to use HTTP API standard simple get API to go get this data so that's why we exposed the scorecard's API that was a specific reason behind this where's the API available the API is available API.security scorecards.dev and we made sure that the API is predictable what I mean is what I mean is you can see here the simple example of hitting Kubernetes, Kubernetes it's a simple code command it results in a JSON output it's got get and post right now I'm going to focus on get but I'll tell you where the post is going to be utilized we also made sure there are no security tokens authentication required for this API so anybody should be able to utilize this API this is a free it's a free maintained by the scorecards team at this moment we don't throttle the API so please don't de-dust this like I mentioned this is serving 1.2 million GitHub repositories scans weekly scans there was at least one star to that is for the past three months we had to we were rebuilding the infrastructure for that we couldn't run but you already have some of the previous data but we have re-enabled so you should be soon seeing all these scans running just enough for our eye we have been seeing about 150k requests per day people using this API who is using this API? we don't know it's a free API sometimes we get GitHub issues where then people come and ask for API rate limits but if you're using this API if you're interested please come and talk to us we are more than happy to understand what people's needs are one of the things that Brian mentioned was code review so we said and there's another system project within OpenSSF called criticality score what criticality score does is it takes the 1 million repositories and figures out which are the most critical and it uses an algorithm by Rob Pike and it uses that to figure out the top we use the data to figure out the top thousand critical projects and wanted to figure out how can what are the what are the state of code review because we realized code review is a critical thing and we use the API along with this data and we were able to graph this why am I showing this so anybody within your projects within your organization you should be able to utilize something similar and figure out what are the state of any of the projects that you dependent or you built looks like most of them are doing well some of them need some help enough talk let's go to code so what I'm doing right now over here is I'm gonna hit these scorecards API but I'm gonna hit the scorecards API for scorecard I'm piping it to JQ because it comes out of JSON one of the checks that Brian mentioned is maintained here is simple as looks like scorecards repository maintained at 10 it's a it's between one and 10 we are doing well on that and let's go back and check another another check for example token permission that's one of the critical checks and gives out results like this as a JSON so you should be able to parse this and programmatically use this looks like scorecard repository itself is needs to fix one of this that's why we ourselves have score as nine let me go back to the slide and if you are interested in you building the building the I use I open source the project for building the thousand critical projects and that's in my personal repository you should be able to pull down that repository and go ahead and build anything similar to this is written go so you but you should be able to use any modern programming language to build that let's talk about the usefulness we're going to play a I am the contributor and I'm a project maintainer and I care a lot about security Brian I want to submit a PR with the new dependency so thank you that sounds really good but you know can you tell me about this dependency is it in a healthy state would a scorecard be helpful Brian I'm not really sure what that is what is a scorecard have you checked out the school cards repo Brian okay so I hadn't but this is great and in fact I think I'm going to be using this API to be checking on all my future dependencies in fact I think I might use it in my CICD tool as well and it's also just so easy to use now I'm starting to wonder just why doesn't everybody use scorecard at this point thanks Brian we've been we realize what what we did and the scorecard team thought about what the API was and we are building a feature to specifically address this it's still not merged in so what this specifically does is anytime a new dependency comes into your repository I figure out what are the new dependency and gives you a get-up comment on the health of the dependency so it's almost like running scorecard anytime a new dependencies added to your repository this is something we are working on it's still not merged in but just wanted to give a heads up of what it is right now so you should be able to see a comment saying hey this is the dependency this is when the scorecard ran for this and here are the scores that you can see so it helps you make some decisions as to what you want to do with the new dependency whether you want to accept or whatever you want to do with that the next thing and then the the scorecard's API was there's another thing that we released last year was scorecard badges the badge is very similar to what it is it shows what is the score of that of your own of anybody's repository so essentially it helps humans understand whether it's how safe that project is so that's the idea behind the badge badge intern uses the get-up action you need to have the get-up action to get the scorecard badge and this is where the get-up action use the API for posting data thanks to Brian we don't want to go install the action manually we Brian recorded this for us so here's an example of a repository now we're going to scorecard's repo there's a specific section how to add a badge and we are copying that going back to going back to original repository going to the readme section pasting that specific content just replacing it with the owner and the repository it's as simple as that if we do that we should be able to get a badge for the repository a caveat and this is if you install the get-up action you get it and if it's part of the 1.2 million repositories that we scan if it's not in the 1.2 million repositories you have to install the get-up action to get the data the another advantage of using the action is you don't have to wait for a scan so update your scores if you install the action the scores get updated automatically anytime the commit goes into your main or your master branch if I have only 30 seconds what can I do I can go to depth.dev get some scores if you have five minutes you can run a scorecard's client get some data out of it if you have 15 minutes install the get-up action should be able to get this score out to the API you should be able to utilize that if you have more than a day should be able to utilize the API and bring it to your workflow we want to make sure that anybody should be able to get some data out of this that's our specific goal behind us if you want to get involved you should be able to hit up the QR code we have a bi-weekly meeting we meet every Thursday every bi-weekly between 1 and 2 p.m. Pacific and that's scorecard's website and the bottom are Brian and mine Twitter handles you should be able to hit us up if you have any questions thank you any questions yes good question do we want to I think we want to repeat it so that it gets on the real the question is how is this project related six-store and S-bomb six-store is part of openness of it's under the openness of Umbrella and just in FYI scorecard's get-up action uses six-store to store to make sure that the action ran it stores the data into six-store store so they are related but scorecard does is not specifically generating S-bombs or anything on that to be specific of whether are we generating an S-bomb we are not doing any S-bomb generation did I answer your question I just want to add I think more generally they're all trying to tackle different pieces of software supply chain security and so you know the open SSF makes sense is this organization above where these projects are fitting but if you think about like S-bomb it's trying to tell us this software bill of materials what is actually in this project and you know once you have that you could pair it with things like scorecard to get a better sense of what these dependencies look like past just knowing they exist and when it comes to six-store being able to actually associate source code with a binary like six-store helps make that signature happen so that those connections are made and so again if you're running scorecard you're running it against the project but when you actually get a binary you can say oh well that actually came from this project so each project has kind of a niche within trying to make the software supply chain more secure but you know are both connected and disconnected kind of depending on on what the conversation is yes good question we have a may we repeat the question sorry my apologies the question is to know the history of the score of a particular project right just to make sure so you want to go back in six months or few months to figure out what are these score of a particular project so we can see whether the project is doing well or not yes scorecard like we mentioned scorecard runs for those 1.2 million get-up repositories as a cron job it stores the data in a BigQuery and that is available for anybody to go query so it's available free for anybody to go query the data so you should be able to get a history for any particular projects yeah short answer yes go ahead do you want to repeat or I can take a step yeah so I think if I heard the question correctly it's because this is an automated process what's preventing a developer from gaming some of these checks like the developer just making constant you know minor changes just so it shows that it's maintained or it's active so you know I think the short answer is there's there's no safeguard in place for it we'd love to get to the place where scorecards are so dependent upon that that people are are making modifications you know just to just to try to boost their score I don't think we're there yet I think as that happens over time we'll have to be looking at safeguards to try to to limit that kind of behavior I think you know the biggest thing is there are there's kind of two groups of checks in this situation there's some that you could game like the maintenance check there's others where you have permission set and that one would be much harder to game and so I think there's also the question of you know what is the motivation behind trying to to game it if it's trying to boost your your project if you care about making sure that it stays in a good security place and that you want adopted my hope is is that people would also say you know I actually just want to invest in making sure I'm doing the right things in the first place but you know it could happen I think this is still a relatively new project too we're still crossing those bridges as they come along great question yes yeah so the quest yeah so the question is is anyone that's looking at different kinds of compliance talking with the scorecards project to see how those would work together you know I think we haven't I would say we haven't kind of dedicated a lot of time to trying to specifically plug in but that is something that that we're definitely interested in I think in general standards are still emerging when it comes to software supply chain security and so we're trying to be part of those conversations and we're working it's part of why we're working you know with the open SSF and working to kind of make sure that we're consistent in how we we act across these different projects that are within the open SSF I will say if there's anyone here that specifically thinks a lot about compliance and would be interested in talking about this I would love to talk with you after this talk and see if there's not a way for us to get plugged in more but right now you know we're more at the these are best practices level and from that standpoint there's not a lot of back and forth debate on it but we have a long ways to go with actually plugging into any sort of existing compliance yep we use GitHub API to figure out the sorry the question is do we understand the dependency tree and do we understand what are the dependency changes so we should be able to generate the SPOM we we don't we don't figure out that we don't we haven't written code to figure out the dependency differences we utilize a GitHub API which gives us the new dependency changes and we use that to go get the scorecards score for that particular dependency so that we can get the results for that particular newly added dependency did I answer your question specifically so not not not not not like that so what happens is anytime a new PR comes into the GitHub repository what we do is we ask and the GitHub API asked to is there a new dependency added in this PR the moment that we get that result we go hit these scorecards API and get results for those new dependencies and populate in the GitHub comment and that's how we know that's how we're able to bring up those details up in the as a comment and I want to make I think one kind of limitation of what we do clear as it is right now which is you're a saying we're not recursively going through because we're not and you know that is something that you know I don't don't exactly know for sure if we would make a hard call of whether that will be something we would ever do or not do but because all of the metrics or all of the checks are at the project level you know basically leave that as an exercise up to whoever wants to consume the scorecard to go out look at their dependencies get the additional scores for them we don't have the concept of like a super scorecard yes you know where you know your scorecard for a project is you know some combination of the best and the worst scores of its dependencies that that part's not there yet and obviously and that's why we built the API so that you can utilize other tools to go get that dependency tree and utilize the API to get the score for that you're welcome any other questions all right going once going twice thank you all for coming thank you


First question I was just wondering if you have gotten the handle on perspective views if you have gotten the perspective on perspective views. The best way to get a handle on perspectives is to practice. So, if you practice you will get better two things that I would want to tell you one is homework number 8. If you guys have the manuals in front of you just check it out homework 8 is slightly different. So, it is a competition. So, this is what the thing is that you are going to be drawing think a two point perspective of your hostel room and that is the fun part of it is that right. So, that two aspects of it one is voluntary voluntary means you can take a break and the second aspect is competition. So, those who are interested they can draw a two point perspective of the hostel room just imagine that you are standing you know just about at the door of your room whatever you see make a mental picture of that and draw a perspective ok. The due date is again one week after your lab 8 and what I will do is I will request the tutors to choose the best drawings from each section and then we will sit down and we will choose the best maybe 1 2 or 3 and of course. So, there will be a little prize that is one thing and second thing is a little request that from now on I mean of course, perspectives would probably have been a little difficult for you, but from now on things are going to get even more difficult. So, we are going to get into space geometry lines planes intersections development ok. Of course, you guys are free to miss classes, but if you miss classes you know you will be at a loss. So, my request to you so consider that as an advice as well as request my advice and a request to you would be to come to the class listen to the lecture if things are not clear to me make me explain it as many times as you want. So, that you can understand it and I will be happy to do that because if you miss a class then you know you lose something you do not feel like come to the next class and then you know things happen. So, this something that I just wanted you to caution about. So, things are going to get a little difficult and challenging and to be able to understand things better come to the class is that a single point two point it is a two point. So, but think about that think about that maybe you can think about that yeah. So, a little more on perspective views this is an example that you are going to be solving in your lab. So, I just want to go through the solution once there are going to be a lot of lines in here. So, bear with me I will try to do my best to explain things alright. So, what is given to you is the plan view of the object and the profile view of the object and a bunch of lines. So, you have the picture plane which is passing through one of the edges of the object p p 20 millimeters below that you have the horizon line about 90 millimeters below this vertex of the object you have the ground line over which you have the profile view this way you are standing and this way your eye level is and 5 millimeters below the ground line you have the station point. So, these things are given to you once these things are given to you you can maybe think about starting to draw perspective views. Now, about this angle and this angle of course this angle is 90 degrees. So, you get a nice perspective if you keep this combination as 60 30. So, length may be around 30 degrees this is more otherwise 60 degrees and the other angle as 60 degrees or 30 degrees depending. So, it is a nice idea because you get a very nice perspective of that alright. So, you have seen this. So, this is the isometric view of the same object that you have drawn in one of your previous labs I am going to be keeping this picture. There is a slight modification rather simplification that I am going to be working with I have replaced this part by a rectangle or rectangular region or a block. So, that we can understand the drawing of perspective in a little better way otherwise this thing would remain the same. So, this thing is a block this thing is a rectangular block, but this thing remains the same over here and what I want you to do is try to understand the difference between the isometric drawing and the perspective drawing as we you know continue with that one alright. So, this is where the station point is I am letting go the numbers and may be be with you I will stay here. So, I can also look at these slides the lines am I blocking you view can you move maybe with the back let go the numbers first step is to figure out the left vanishing point and the right vanishing point this for the left this for the right you project the object far away along this direction on the horizon this for left vanishing point on the left LVP on the right vanishing point on the right. Let me go back starting from the station point look along this direction at an object at infinity get the image of that on the picture plane which is going to be a point project that on the horizon line this would be the left vanishing point likewise if you do the same thing on the right look along this direction at an object at infinity get the image of that object as a point projected downward on the horizon line you will be getting the right vanishing point first step with me good now what are the three rules lines which are parallel to the perspective parallel to the picture plane remain parallel one full lines which are not parallel to the picture plane they vanish lines which are on the picture plane they stay in true length identify the first step is identify the edge on the object which is on the picture plane look at this vertex here look at this point. So, the edge going into the screen will be the edge which will be in true length ok once you have identified that from the station point view that edge ok that edge would correspond to this here make that edge now with that edge made these edges are going to be vanishing towards the left vanishing point these edges they are going to be vanishing towards the right vanishing point alright left vanishing point the right vanishing point let us focus on this edge from the station point in the top view get these slight information ok the image of this vertex will be formed over here projected downward you will be getting the edge in between these two rays that vanish towards the right vanishing point here with me ok. So, once you have this edge you can get this block made pretty easily ok now of course you would not see this edge because it is not there, but how about this you see this alright where will you see that on these two rays ok what you do station point look at this vertex get the image of this vertex on the picture plane project that image down ok. So, you will get this edge here right over here in between these two rays ok the same thing for this vertex here get the image on the picture plane project it down and you see this with me straight forward straight forward. So, you have this part ok now how about this feature of the object here all lines at 60 degrees from this part of the picture plane they will be vanishing towards the left vanishing point now ok. So, if you are looking at this edge over here and this edge over here they will be vanishing both towards the left vanishing point with me ok alright. So, both from the top as well as from the bottom now this is the important part this guy here in the profile view where is it where is that in the plan view over here right now would any part of this be on the picture plane no will you be able to get the true height of that will you be able to get the true height of that probably not ok, but there is a little trick that you can use to get the true height of that ok. So, you can just imagine you can just imagine that this guy comes down over here. So, that one of the vertices of this guy is on the picture plane correspondingly get the height of this thing on this line ok because it is this line where you are going to be getting all heights in true lengths no yeah ok. So, imagine that this guy has come down over here imagine that this guy has come down over here. So, that this vertex is coinciding with this vertex ok working ok I will try to speak without the mic for a while can you hear me good. So, are you with me with regard to this now look at this edge where is it going to vanish there what do I need to do now I use the side information I look at the back vertex of the object in top view get the image of that on the picture plane project it down ok what this edge is that is this edge in perspective ok how about the height are you with me on this so, get this height. So, let me go back. So, what I have done is a little trick I know that if I stay on this vertical line if I stay on this vertical line I am going to be getting true lengths can I have some you know it is bad you should share all right. So, what I do is I will do a little trick I know that anything on this line I will get in true length. So, I will move this feature over here. So, that one of these vertices coincides with this vertex ok. So, that means that if I take if I use the profile view and get the height over here what I can do is I can knowing that it is going to be vanishing at the left vanishing point I draw this ray and then I use the side information look at the back vertex get the image projected downwards this would be the edge in perspective corresponding to this edge and this would be the height in perspective corresponding to this height. So, first of all I look at the second vertex get the image projected down and then looking at these edges I know that they will vanish towards the right vanishing point both then if I look at these two vertices essentially I am going to be using the side information if I look at these two vertices I go up get the image of that vertex on the picture plane projected down likewise this one projected down I will get this block which corresponds to this guy over here fine. So, first of all same trick same trick to get this part of the object use the profile view project the height on the true length line draw rays that vanish towards the left vanishing point and the right vanishing point.  So, far or maybe I can go back and I can explain no stay with me here you know it is not your fault because even I am getting confused stay with me do have this point on in my perspective figure do have this point in my perspective figure do I where is that this guy over here I do not have it how do I get it I know that this point corresponds to this point right I use the true height information take this ray towards the left vanishing point this intersection point is that right this one over here would correspond to this and this. So, once I have this intersection point ready I look at this edge over here this edge would vanish towards the right vanishing point having done that I can draw this edge this vertical edge and the vertical edge on the right here and then I can join this and this point to get this slant surface good how do I get these points stay with me I have gotten this edge now I have gotten this edge. So, there is a trick that I can use what I can do is I can project these two edges right. So, once again I can project these two edges onto this edge I get these two points over here I look at one of those points from the SP in the top view get the image I look at. So, this point over here. So, this point over here comes down over here right ok likewise I look at this point I look at this point from station point this is the image of that point on the picture plane I project it down over here and then I join these two points and I get these two red lines corresponding to these lines over here and over here fine with me which horizontal line there are many horizontal lines there are. So, many lines that yeah come yeah yeah no you know why why absolutely absolutely. So, this portion cannot be here because this portion is behind the picture plane. So, this horizontal line here is just to take the true dimension of this on this true length line all right. So, stay with me this confusing there will be lot many lines right. Now, I am looking at this point I am looking at this point here and I am going to be taking the projection of the image of this point from here which is this here I know that this edge vanishes towards the right vanishing point I draw this edge and the intersection of this ray with these two edges will give me this edge can I repeat ok so far. So, what I have done what I have done is I have located these two edges in perspective fine I have to locate this point and this point ok how do I do that I go to my station point which is where I am I look at this point get its image on the picture plane project it down where on this edge ok I will get this point over here likewise I look at this point get the image on the picture plane project it down I will get some point over here. But, I do not need to worry about that because I already know that this edge is vanishing towards the right vanishing point. So, all I need to do is draw a ray from this intersection R B P which is what I do here fine yeah of course you can there are multiple ways doing that of course you can this is one of the solutions ok. So, this part this part of the object is in perspective now yeah needs a clap come on now is it possible is it possible for you to draw the right hand part right inside the object in perspective no want to see things messed up yes which one why yeah yeah yeah stay with me stay with me. So, one of your peers says that this object is not complete because there would be a vertical line and there would be another line and there would be another line three lines missing fine do not worry about that this is just for check this is your vertical line. So, in your slides you can go back and refer to the blue lines and this is just for verification do not worry about that vertical line that if you draw a ray joining this point and the right vanishing point the edge below this edge that lie on that ray extend that and then you will be getting the third line all right. So, here comes the messy part of the object what am I doing here from this vertex from this vertex I am drawing this edge in perspective right there you go and then the edge on top of that it is getting mess here not visible you know it is going to be interesting if when you are going to be working on this is going to be interesting it is going to be too many lines too many lines too many lines too many lines all right. Now, I want you guys to be attentive and just see just see what is happening on the right hand side of the object from the station point from the station. So, the idea is that if I am able to get a perspective sketch of this portion of the object I think I will be ok. So, what I will do is I will first of all simplify this thing to be like a block once I get this like a block I can then try to get this semicircle and the circle later the first thing is for me to get this part the object as if it were a block let us do that I look at this vertex from the station point project it downwards this what is going to be lying on this edge this edge in perspective is this edge right there I get this part. Now, look at the point at the back this point over here this is the intersection point which needs to be projected downwards this intersection point is what we are interested in and as I said I am looking at this part as if it were a block. So, I draw three blue lines look at one vertex take it down extended extended look at the other take that projection down extend that I get the block I get the block right. So, once I get the block then getting the circular feature is not going to be difficult we messy all right it is not going to be difficult this is your centre line.  So, these lines are going to be intersecting this arc and I am going to be doing the same treatment to those points of intersections as I have done for all the vertices of the object this is what the generic idea is wait and watch line in the middle wait and watch got that line getting the points of intersections I guess got that line got the centre line got the arc got this part of the arc one solid line should not be there should not be there should not be there should not be there which one is it this one ignore it yeah I should not be there ok there is more mess pertaining to the circle from where to where all right. So, let me have these guys over here and then maybe I will explain it now this block was fine this block was fine what I wanted to do was to get the arc in perspective ok. Now, how would I do that or how would I be able to do that I draw a bunch of lines which are parallel to these lines get the intersection you get the intersection between this arc and these lines I will get a bunch of points set of points a group of points and I am going to be dealing with those points the same way as I have dealt with all the other points that is what the basic idea is wait and watch the mess pertaining to that circle over there again the same thing I am going to be enclosing this circle within a box get the box in perspective get the intersection points and eventually get the circle wait just watch run a little fast working all right bottom line bottom line hold on hold on come on stay with me stay with me once again the idea is to enclose this circle within a box get the box in red over here in perspective make that circle intersect with a bunch of parallel lines get the points of intersection perspective draw the corresponding thingy and of course, there would be a there would be an arc over here if you think there would be now this is what is what you should see at the end of your lab 8 I wanted to cover 3 point perspective, but we do not have much time and I have to wind things up in another 4 and a half minutes just an animation of the 2 point perspective of a staircase arc ain't easy. So, this probably answers your question. So, depending on the height of the object you have it is below the horizon line you are going to be seeing the roof of the object if it is above the horizon line you are going to be seeing you will not be seeing the roof of the object. So, essentially all these guys are this is the horizon line all these guys are below the horizon line and that is a reason why you are seeing these flat surfaces above the horizon line those flat surfaces are gone. So, it has been 8 months since you have cleared J E 8 months yeah almost more than 10 months alright almost 10 months since you have cleared J E fine this is where you start in your careers in your respective careers this is where you start this is where you are 10 years done the line when you come and meet me ok I would want to see you way up there in your lives thank you.