Excellent. Thank you, Candace. So yes, I'm excited to spend the next hour or so speaking with everyone and welcoming you to this conversation about addressing cybersecurity challenges and open source software. This comes on the heels of joint collaboration between both sneak and the Linux Foundation of authoring our annual sort of state of open security report. So recently released what we'll be doing is actually going through some of the interesting data that was gathered through that report and sharing some of the common themes discussing those discussing, you know, potentially some of the trends and reasons behind some of the information that that we're seeing. So, without further ado, it's best to probably start with some of the information and insight and details as to what did the report consist of. How was it created what a little bit of the background behind it as I mentioned, it was co-authored behind between the Linux Foundation and one of the authors is joining us on that the call today Steve, as well as information and data specifically from sneak information and some statistics in order to share some insight of what we're seeing in the industry. The research for this report started back in March and as part of that research. In order to build out the surveys and the questions that we wanted to ask of the industry there were multiple interviews 15 different interviews that were performed in conjunction with open source software maintainers cybersecurity experts to make sure that we were in the right questions of the information and data that we wanted to to extract the survey itself launched in just April of this year, and it actually targeted a fairly broad spectrum of individuals so everyone from open source software to core contributors, some occasional contributors, developers of software that actually using and consuming that, and other individuals that were focused on the software supply chain. So, broad spectrum in addition to going across many different industries everything from from small organizations with only small handfuls of developers to, you know, some sample sets of organizations with very large developers. So, the combination of the survey results as well as just information that sneak is able to gather based upon our interaction with a lot of our customers is the information that shared in that report. There were over 550 survey respondents. The interviews we talked about and those actually also spread and we focused on sort of five key language and ecosystems that are shared in the report. So with that said in order to make this a little bit interactive and what we do is what we thought we would do is, is queue up a quick poll. And it's to get a feel for everybody that's on this this meeting to maybe share some of your thoughts as far as when you start looking at open source and software and and the concepts of direct dependencies and indirect dependencies and some of the themes that we saw in the report and that were shared. What is your confidence level as far as understanding your security risks in your direct dependencies right the, the open source components that developers are pulling into your applications, as well as the confidence level in indirect dependencies and so for for some of you that may not as be familiar with with open source software indirect dependencies are the ones when when you pull it in open source package. You can actually have a dependency or use other open source components and those components might use other open source components and so you get this hierarchy right this parent child relationship, and those lower level ones are the indirect dependencies also sometimes referred to as transitive dependency so what is sort of the security risk associated with those and your confidence level and understanding if you're aware of those your organization. Interesting aspects that we were able to derive in one of the themes that fell out of the report was the open source security has become basically a greater challenges, but especially as part of the software supply chain and and I think last year it was evident that the software supply chain has become a big focus from a security perspective as we saw greater sort of attacks and different threat vectors. So it looks like we've got the poll results. So this is, it's actually very interesting. So I see direct dependencies 15%, somewhat, you know, as far as very confident, somewhat confidence, three quarters of you which is actually pretty, pretty confident and then not confident about 11% looking at the audience they're using software composition analysis. Good for Matt. Indirect is very confident we've got 4% somewhat confident at two thirds which is which is pretty awesome and then not confident, but the intriguing part to me was one of these data points that's actually in the software software security was 24% of organizations. So even a little bit higher we're actually had high level of confidence in indirect dependencies but that shrunk to about 18% in indirect so not. If you look at the very confident not too far off in there but maybe even a little higher and probably somewhat in between the mixture of the two so interesting to see some of these poll results. With that said, some of the numbers that were shared in the report and some of the again so these are very intriguing ones when you start to get a lot of the collective data from from across the order across the globe right some of the the information is shared with what organizations are using and one of the things that was shared and set the report from from the data was projects that are using open source software on average have about 49 vulnerabilities and these 49 vulnerabilities and again, on average are spanning about 79 direct dependencies now that that varies significantly across, you know, sort of some of the ecosystems and on the right with what shared here is what those ecosystems represent right how they actually influence the the averages that you're seeing one of the other interesting and this is again more and some of the details in the open source report was that the vulnerabilities themselves on average 40% of those are actually within indirect dependencies meaning they're buried a few layers deep so with this I would definitely love to get, you know, Steve, Matt, especially Steve from an authoring perspective, some of your insight as far as you know, are these numbers surprising. Do you feel like there's an increase in open source usage and any sort of insight as far as we have these vulnerabilities what's what's sort of the difficulty associated with with addressing them and fixing them and things that you're seeing in the industry. One of the first things to say is that 98% of organizations use open source software in some capacity whether it's unrestricted or with certain kinds of conditions. So open source is everywhere realistically from the standpoint of dependencies you know we're transitioning from to an approach for developing software and we have been probably for the last close to maybe five to 10 years, which is very much on microservices. Some modern application development really does rely on smaller components, typically that have dependencies on other components that's just stylistically the most efficient way to build build software this these days. And with lots and lots of open source components out there and being created every day. There's a real advantage to being able to from a time to market perspective, and potentially even quality, depending upon the quality of the components being used a very strong rationale behind using open source and not being overly concerned about the number of dependencies that I would expect the number of dependencies both direct and indirect to rise over time from the standpoint of applications get developed. And I don't think that's a concern because of course we have tools that allow us to look very closely and scan across the portfolio to find out you know where all these dependencies are where particular components being used across the portfolio. Not a concern, but you know once again, you know good governance, you know risk and compliance controls need to be in place. Yeah, I mean I think you know it's it is important as Steve alluded to that this, this model of developing modern applications you know in terms of what we think typically is somewhere like a 80 20% split of hunger and these, you know, pre package modules pre package libraries that have been brought in that's been a tremendous driver for innovation, because it means that people don't have to reinvent the wheel. You know, and it's really enabled people to to speed up tremendously, you know, the software development process with creating much more software. And so there's been a generally a very beneficial thing but you know clearly, you know open source has become somewhat victim of its own success in that that that sort of ubiquity has now made it a target for bad actors you know attacking the supply chain is in many ways probably an easier target than than looking for zero day vulnerabilities in directly in in applications right and you know that's what we've seen as a trend generally in the industry, you know, we see more and more of these things like type of squatting you know directly in the package repositories, I'm trying to trick people into into using alternative things without without people realizing that they were doing so. I think the, the, you know, clearly the, the 79 figure there's the kind of average of averages across ecosystems and we see on the right hand of this slide. There's a lot of variation. You know, I did get asked as a result of this slide should should software developers be looking to stop using JavaScript because it's clearly, you know, more more dangerous than the other ecosystem. But you know, there's things in in this differences fundamental differences within these software ecosystems that will tend to sort of skew these numbers you know JavaScript packages tend to be much smaller in scope. There's a lot more choice available within that ecosystem for things that do have a specific function in comparison to, you know, something like Python where there's a, you tend to have one one package that rises to the top that does all the things for that particular function and what it does say within those package ecosystems is the clearly where you where you have many more dependencies on average in a project in JavaScript, for example, that that makes the scanning and awareness of vulnerability to potential vulnerabilities in the code probably more important for you to consider because you are pulling in pulling in, you know, more more third party packages there. I mean, it's worth saying that, you know, the given that the packages tend to be smaller in scope, you know, this this that you could put an argument together to say well, there's less code there right so you know that it doesn't directly translate into more vulnerabilities being in JavaScript than anything else but it's, it's definitely something to be aware of for developers within those particular ecosystems. And Matt, I'm glad you shared that that sort of ubiquity comment because as we see some of these larger frameworks being shared across organizations, I would agree from a security perspective path of the least resistance is always the most attractive ones from attack perspective it's it's the easiest way in those common grounds and then simultaneously I think I believe this is echoed in the report to we're seeing a growth in just open source packages right this continues to grow and grow and expand which means there's a broad sort of spectrum of what can be used to consume and I think both of those start to bring sort of their own sort of unique implications. Yeah, absolutely I mean you know we have we have the idea that we use inside sneak showing you know in every package ecosystem massive trends of upwards into the right and you know, well I guess we'll touch it a bit more on, on the implications of that idea about more software being created on some of the numbers that we get to later in the deck right. Yep. Absolutely. And that said, one of the other things that was an interesting sort of theme and actually potentially surprising. And I know that was shared inside of the results and some of this directly came from the survey itself is that there is still a lot of organizations that don't have the open source sort of security prioritized. The statistics and the information that was derived from the report. What what you can start to capture and one of the things that was shared was that currently across organizations only about 49% of them at least from the survey respondents seem to have a security policy in place that addresses the open source software and if you look on the left of the hand of your screen here too you'll see that it, it does vary across sort of the organizations and size of the organizations right the dark color they're representing one to 500 employees and then sort of growing as you look at the green and the yellow where it's 500 5000 and 5000 and above. And what we start to see is, you know, how many of those currently have one in place. And then those that explicitly answered no and sort of, I think one of the more surprising ones, you know, you kind of expect that on smaller organizations right newer they're just starting up they're just starting to get programs in place and so building out that is is typically part of an evolution of an organization is is putting a little bit more of those stringent controls the more you grow in order to address the risk. And then probably on the other side is as you look at larger organizations you kind of expected that number to be maybe a little higher maybe a little no lower on the, the no side so curious again from Matt and Steve from from your perspective talking with organizations what what your thoughts on this and then probably a side conversation of what what what you see as an impact of some of these responses rightly, and I know that's a loaded question, but the impact of, you know that the don't address it being about 30% in very very large organizations 27% is shown here. Well, let me, let me comment on this first. So the origin of 49%. Just see on the right side of screen is actually the overall number of organizations in our sample for this particular survey that said that they have a security policy for open source software in place. So 4% overall said they don't have a security policy for open source in place, and we had 17% that said don't know. So, it's okay in this particular question to actually sideline that don't know not sure is. And if we do that the ratio of having an open source software policy in for security versus not having one was six was a 6040 split is dismal as it sounds but I will say there are some very alarming characteristics to what you see in the chart here. The fact that we can have organizations of all sizes have at least 27 at least 27% of them growing to 44% for the small organizations, saying they have no open source software policy in place is actually very. But it's alarming to me, because, as I said earlier, we know that 98% of organizations use open source software, not having a policy in place, the standpoint of how you want to do GRC for open source. It's just infighting in, you know, it's, it's, it's setting the stage for catastrophe, realistically. So, I think to me that's very alarming and from the standpoint of what the impact is not having an open source security policy which you would think would be a relatively risky offshoot of overall security policy means that you really have from an open source standpoint, no way to manage the governance, the risk management and the compliance of what you're doing with with open source software. And as I said, because it's so widely used that's a that's kind of a recipe for disaster. There's a couple of interesting trends that that are that are kind of, you know, that you can that you can view this data through through a lens of right I mean, I think if we if we went back, even even five or so years, I think you would have seen a smaller number of very large organizations with open source security policies, I think in large enterprises, you know, you, you might, you might be on the one hand you could you could argue that that, you know, large enterprises much more resistant to change, and they have a lot more ingrained kind of, you know, legacy applications and all that kind of stuff. But I mean actually we've seen over the last few years, a massive rise in open source program offices within within very large organizations and, you know, typically things like this if you if you've got an open source project office you're going to be all over this because that's what the role of your open source, open source program offices. And I think as well the, you know, whilst, whilst the, you know, we can talk about the no figures when we look at 40% plus of small to medium enterprises having an open source policy, you know, I think that for particularly when we look at the kind of startup world, you know, these, any new entrant these days is in who's who's a tall technology company and you know, we have to make the assumption that most, most people starting businesses at this size are going to be have technology at the heart of what they do. They don't have that legacy there so they're starting they probably have a development and engineering teams who are, you know, used to working with open source they've been doing it their entire careers. And so, and then and their greenfields so then, you know, makes it much easier for them to adopt new technologies and, you know, understanding of how to how to best leverage open source. Yeah, those are, those are both great points and I definitely like the perspective that, you know, an organization that's been in motion had this solution and adoption that probably affected their business fairly quickly versus, you know, some of the agility of it's just common place in the, in the newer ones as the startups to have something in place because it's it's a known entity right you're you're starting with with that so might as well start to tackle it as soon as possible. And the interesting part again is is, as we saw a lot of the, the threats and some of the attacks last, you know, over last year that it's becoming a target. We've, we've discussed this will talk about some of the software supply chain impacts with some of the vulnerabilities on a little bit but it's an interesting area where I think it's, it's by no means going away and definitely growing in sort of presence. One of the other things that I think that was an interesting statistic that was shared in this, this report was for those that do right for those that are actually leveraging open source and for whether or not even there's a security sort of policy in place but what sort of components and approaches are in place in order to look for those risks right to, to maybe proactively identify and understand as, as you're starting to use somebody else's code. So what, what does that what risk does it pose on your organization and can you be proactively aware of any of those and take action, one of the stats that came out. And again, want to want to share and Steve I'm going to let you give some insight into these numbers and what it actually entails and how you see them, but 44% of companies have have some sort of approach with developers or other types of approaches and the source code in order to look for these risks. And then we saw sort of multiple sort of categories in these responses of different types of approaches in order to say, What is that risk, like what, what is that level of trust associated with it and can I identify any of those sort of an a proactive method and so it was interesting to see sort of some of those and which ones are more common across the different different organizations. Yeah, two key points here first, the 44% bar that obviously the tallest one. The response there was we use tools to examine source code, open source source code. And what that represents is sort of a holistic view of, are we using tools and tools could be are typically prompt, typically going to be dedicated open source security tools. Like SCA, stast, DAST, and IAC, well that's not dedicated security but it has a big impact on security. There's not 10 categories overall of these kinds of tools. A lot of these tools are in use today and they're very effective at helping improve your security posture. So, so it's good to see that nearly half of organizations are overall are using tools. Many of the other bars are really interesting because the subset of them essentially say that the community that stands behind the open source component that we are looking to use is vibrant it is responsible it has the right kinds of people and it has some core contributors in it, and the right kinds of cycle times to be to give us confidence that there's a care and feeding of this particular component is ongoing. And this is a component that we can have a level of trust in. So I think those are the two things that kind of jump out at me on this question. And from my perspective what's actually good to see here is that, you know, we're, as well as focusing on the on the code what we're seeing here is at least some level of understanding about what the key kind of metrics of health, you should be in open source projects and, you know, it's not just about about function, you know, when you when you're looking at using and integrating something open source you really want to be looking at, you know, how healthy is that developer community, you know, how often are people committing to it, how wide a developer based as it have, and what's the governance of that project right because, you know, we've seen it recently with some of these ransomware things in the community like the colors and faker incidents where we have a single maintainer projects where the maintainers kind of on rogue and, you know, put in code that potentially can cause problems to to users or in other cases have removed the functionality of the product altogether of the project altogether. And so, you know, these things about, you know, looking at package download stats looking at commit, commit cycles releases, you know, and, and, and, you know, checking what the governance of the project is is, it's good to see that people are recognizing that those are important things as well as just purely focusing on the code and I think we're seeing a evolution as well in the kinds of tools that are available to people to make those kind of judgments, you know, for a long time you might be looking purely at commit histories or you know if you were working GitHub looking at stars and that there's a kind of quite very broad brush metrics in a sense but you know we're starting to see things like with the open SSF scorecards program, you know having ways where we can even programmatically assess whether a you know what the security kind of health of that of that project is overall. Yeah, I think that the one thing it building on both of those that that I think was interesting to me is this, this starts to actually build almost an industry best practice and some of those judgment protocols like looking I mean, check in to see if there's a responsible disclosure policy and an open source package is an interesting sort of approach right and then looking at Matt as you just mentioned the maintainers and that trust sort of mechanism as well as automated solutions to provide that that guidance for you but all of these sort of multiple layers of knowing, you know, is this something that I have confidence in, and can have that trust relationship and there's these are multiple sort of layers of judgment. I mean, I think that that security, the fairly low scoring of the security MD is interesting one because, you know, the security MD is a kind of community sort of standard that's been around for a very long time in open source communities, you know we have kind of best practices of having a number of these files exist in the root of an open source repository things like contributing to MD, which is going to give you information like trips into the project and the security MD is actually a very long standing thing but it's interesting that not many people consider that to be, you know, an important health metric. One of the things that this also suggests and we haven't talked about, yes, our, yet our software bill of materials. That is a very important dimension of solving this particular problem. It was instrumental in helping the Lynch Foundation put a report out on it at the very beginning of this year so check out that report on software bill of materials, if, if you have an interest in that it's very comprehensive work, but with respect to what it is here there's there's three things that a software bill of materials gives you, it gives you a lot of understanding about the existing component. And so there's a very rich metadata. And that is instrumental understanding, you know, who was responsible for it, what is the, what is this all about it's got the source code. Also, so, so it gives you that rich source of understanding about what this component is what it's supposed to do and information about its license information about its vulnerabilities. It has info on what's been what's been fixed. And then by looking at the various, you know, registries, either US focused or worldwide focused you can sort of deduce what hasn't been fixed. So this is, this would be absolutely critical from the standpoint of understanding the knowledge that's having trust in it because this information is non falsifiable and understanding usability, which has to deal with its licensing. So, as bombs are a very important part of the equation here. We didn't spend a lot of time on this particular study but still very important to recognize. Yeah, I definitely see I think we'll see that as a as a theme as we discuss some of these other the other interesting part about this and that kind of building on that that security and db and a prominent approach is also that it illustrates that there's many different vectors and so it can be sort of intimidating and burdensome in order to actually investigate though. I think a little bit of that the themes I think that was derived out of this report about reliance upon other entities in order to help provide some of that guidance which I think is critical. It's also captured here right we can see in some of these stacks about relying upon the community relying upon, you know, vendors and solutions to also help provide some of that guidance because it's, it's, it's definitely, you know, it puts a big burden on individuals in order to try to do this across the board with every single one, especially when we talked about the average being 80, 80 or just direct dependencies within within an application using open source software. I think ultimately at the end of the day where we need to have an automated approach to how to deal with all this information and I think that's within reach at this point. Yeah, I mean in some ways the scorecards stuff plays into that you know that's all about a standardized format that can be read programmatically straight out repository with, you know a whole set of sort of health and security metrics in there that that can be interpreted programmatically. Awesome. Well, let's let's transition and talking to probably one of the more prominent sort of discussions that happened last year, and some take takeaways that I think you know you when you start to look at some of the details and some of the information that that shared as well from from the commercial vulnerability so you know, December last year I think anybody in security was probably very well aware of some of the scrambling associated with trying to identify or immediate a lot of the impact of a very prominent open source package and Matt talking about some of the ubiquity you mentioned before about a very, very common component that very popular and used across the industry all of a sudden had this this this risk exposed and sort of the scrambling in order to actually address those. A couple of sort of intriguing elements that I think that that were shared was. And some of this is again from what was seen is that you know 79% of applications that had this log for shell vulnerability log for Jay had more than once right it was it was actually embedded inside of the application multiple locations. And the other interesting one and this is one of those things that we talked about when you start to look at the complexity of open source and the open source relationships and the hierarchies and one of the reasons Steve like did like you just mentioned that that software bill of materials that I think is is extremely critical is understanding that hierarchy relationship and having it both for reference as well as communication and documentation. This illustrates that you know when we looked at some of the, the data that 60% of instances of, you know, log for Jay vulnerabilities as part of the log for shell sort of exploit was found in indirect dependencies, meaning it was potentially buried several layers deep on another open source package that relied upon it, which meant you had to figure out what the solution was, and probably a slightly different matter so we'd love to get sort of the insight and takes both both from you and Matt and Steve on any sort of impacts that you saw and how you saw organizations actually handling this right what what was some of the approaches for some of these complex sort of problems that they had to deal with. Sorry. Sorry, you start. Now I was just going to say this is this is kind of a almost if you if you wanted to come up with a perfect illustrative example of this whole problem space, you really couldn't have invented one that was that was any better than this right you've got a a logging component in Java incredibly widely used it's basically you know the standard way to do this in in Java. It's in an ecosystem that is, you know, used gigantically inside enterprises, you know, people with huge, huge amounts of internal software business, critical software written in Java, and those kinds of Java applications tend to be, you know, complex multi layered with dependencies, you know, lots of indirect dependencies. So, you know, this was a perfect storm, really, and I mean, you know, it's, it's, you know, having, having a component like that that is used by almost everybody is not necessarily a bad thing and I mean under a lot of circumstances you would have thought you know the kind of Linus's law thing about eyeballs would have would have been, you know, for those of you who aren't old enough to remember this is that, you know, I'll paraphrase a bit because I can't remember Eric Rayman's exact terminology but you know that that all all bugs are shallow and given a large number of eyeballs. But you know this was really just a use case that people hadn't considered when a particular commit was put in this is going back some years.  You were going to have a problem. And I mean this is still going on right because there's also a huge exposure to this in the embedded space and you know embedded devices if there were something splashed into hardware is a much, much harder problem to upgrade than than enterprise applications. Yeah, in many ways this is a perfect advertisement for software composition analysis tools, because these tools with some vulnerabilities and identify these tools can go out and tell you where all the instances of that those vulnerabilities are. And once you know where they all are, you know, you can do automated remediation potentially although I certainly are testing. If I was going to go down that path. But that, but here's a great example of how tooling can provide a very effective and scalable way to go find the problems and help you get them, get them remediated in a very, very short order. I think there were fixes available for this very, very quickly once the exploit been out in the wild. And, you know, if you were using SCA tooling you were able to find and fix it very quickly. But I think, you know, what was clear to me when you know with my with my kind of sneak hat on was that it there were a lot of people who didn't have software composition analysis in place, who was suddenly scrambling to find a software composition analysis. We certainly had a very large spike in new users during this during this period. I think I just make one more point here you know which is kind of, you know, again slightly slightly tangential, but you know, because you could argue well we should never have, you know, applications that are ubiquitous because they're always going to be, you know, a point of attack but I think probably if you looked at the, you know, the total cost of development for for every, you know, Java application to have written its own login code versus the cost of remediating long for Shell, you know, you may find that that it's that it's surprising in a very large ecosystem like that, right, because we'd be talking about millions of hours of developer time that that would be required to The Linux Foundation for years has had research going on to understand what the most widely used, you know, so many different categories and identify the top 500. So, this is all being done on purpose so that we know what's widely used provide a much higher level of scrutiny on those highly used components. So that issues like this will be in hopefully far less likely to happen in the future, when we get more more emphasis on security And on SCA tooling, there's a statistic in the report, although not in the slide deck here, 46% of organizations in our sample use SCA tools. So we don't even have a majority using them yet and it was probably why, as Matt said, the scramble for for use of that technology after after I was just going to say, I think that that scramble is probably illustrated by the stat on the right, right, it's, it's one thing when you got a direct dependency it's fixed you simply replace it. It's, it's another thing when you're trying to figure out the hierarchy in a relationship and it's not just something you go to you go sort of, you know, directly upgrade yourself this is also very a situation Matt to your sort of point about being a perfect storm to me also like rolls back to one of the other themes that we saw earlier why the criticality of having some sort of a security policy associated with open source becomes so critical because that starts to dictate the software build materials that starts to dictate, you know, having some sort of solution in place that so that you can not only be proactive of having the ability inspect and find things and take the appropriate action but when situations where you need to be highly reactive, you know, are dictated you've got a plan in place in order to actually execute on those which is, this is exactly what happened here is it was a highly reactive sort of situation and understanding your risk was extremely critical as part of being able to take action in reactive fashion. Yeah, I mean if you're doing this manually would just be impossible I mean you know, there's, especially in an enterprise I mean you've got to have automated systems in place here that are maintaining that that list and that list comes from, you know, scanning of some description when during your software development lifecycle. Excellent. So I think that actually rolls well into I think one of the other common themes that we saw as part of some of the information that was shared was, you know, finding a solution a complex solution for this complex problem, you know there's there's a lot of different approaches across the industry and it was interesting to see some of the data that was shared as far as some of the, the trends that are in the market, both from one, you know, looking at open source itself and then looking at organizations and how they're handling from a, from a first perspective. We have seen a very interesting one and I know there's, there's probably many sort of stories and reasons why a lot of this. This may have happened but you know the time to fix vulnerabilities so if you look back just a few years ago, 2018, you know the average time for open source to actually remediate issues with around 49 days. Next, it's, it's gone up based upon, you know, some of the, the, the, the data that we were able from a state perspective in order to, to share. In addition to that fixing vulnerabilities so the approach to actually solving problems when there's open source involved is actually potentially takes a little longer than, and you know fixing those in the open source takes a lot longer than some of the first party codes that's being used inside of organization so I know, you know, Matt Stevie probably got some insight that that I think is extremely interesting to share as far as the reasons why you believe we're seeing some of these trends like it doesn't feel like it's a good thing, but it doesn't mean it's also bad. Yeah, this is nothing more than this is to be expected this is the sign of the times. The years is quite a long time, especially from the standpoint of how security has evolved, and, and the use and how the use of open source software has a dramatically increased. So, we've got organizations building more software today because it is such a strategic advantage for them. We've got more open source software componentry, you know, coming into the marketplace. We've got greater emphasis on security these days and looking across the lifecycle of that dev to be able to deal with security issues. And there's lots more observability and visibility into vulnerabilities. So I think a lot of this is conspiring to find more information these days relative to what we had at our disposal in the past I'm not surprised to see this number go up. But I think the one thing I would say is that when you look at the profile of vulnerabilities and those that are most critical. Those that are most critical are typically a smaller number, even by language, and they get resolved very quickly. But with all open source components we have many low level vulnerabilities that you don't also need to be resolved, but because they're low level. They're not important they're not going to cause or lead to huge exploits, potentially, then that means those can sit out there for a long time because of resource issues that pretty everybody has. And that's to be expected that the number will increase but it doesn't necessarily indicate that that's about that. Yeah, I mean, you know, looking at looking at the whole of ecosystems in in kind of aggregate is, is, you know, not all projects are created equal either right I mean you know we're a very broad church in the open source community from, you know, huge scale projects like the Linux kernel like Kubernetes where almost everybody on those projects is a is these days is employed by a company to work full time on that project. And you know for every one of those, there is 10 or 100,000 tiny little projects that are being done in someone's spare time. So that when you when you're developing something in your spare time and you're trying to develop new features you're trying to support your user base. You know, there's a limited amount of resource there and I think Steve's perfectly right there that what we're seeing is this sort of low level of vulnerabilities probably more. More towards the low medium type of severity. And that's growing, because, you know, we just haven't got the resources and across a lot of projects for folks to be to be to have time to fix them and also having access to the kind of information to be able to fix them right. I mean, you know, this is this is what the what the one of the open SSF missions is to provide that information to to open source contributors to open source maintainers, you know, to provide tooling and security information at scale to, you know, the to to a wide, a very wide range of open source projects and so hopefully those initiatives as those start kicking will start to see this, this maybe slow down this trend and you know ideally reverse but. Yeah, I would agree and I do like the theme of Billings Foundation of pushing more for community and giving back and getting more individuals involved in these because they think that will have a direct impact on some of these types of changes right there's organizations large sort of open source projects have a lot of resources and a lot of people working on it, the smaller ones and I think one of the statistics was 30% of a lot of open source factors have a single maintainer and some of none. And so when when you're limited all those resources it makes you know the ability to change some of those things a little bit more difficult because it's not always your, your full time job or your first. I mean, this is going to be a two pronged approach here you know this from the end user perspective, you know clearly as we looked at the policy numbers and stuff like that we've still got some way to go in educating end user organizations about how they need to manage their risk in terms of open source, but at the same time, you know we've got to provide resources and and and support to the grassroots community level, so that they can get better at doing better at doing security as well. Excellent. Things that was extracted from some of the data was with some of the approaches that are being used by the industry as far as like, so how they tackle this how do they look for security vulnerabilities and I think and maybe obvious but it's probably one that makes sense and consistent that we see some of those when we look at you know some of the solutions that are being used in the market in order to address discover remediate these types of approaches that SAS static application security testing. We've mentioned SCA software composition analysis right or are some of those unique approaches but then we also see some of additional ones that are in there so interested a little bit on on your feedback as far as you know is this the surprising you know is this lacking or you know some of the other areas and I think one of the other things we haven't talked a lot about is just education to which sort of component of you know how we actually approach this in a more effective manner as well. This is this is a very good sign this particular chart because it shines the bright white on SAS and SCA tools. And those are the really the two most popular tools and have been for a while, when it comes to dealing with security. This particular question doesn't tell us but it does, but we see it elsewhere in the report are that infrastructure is code IAC tools are used quite a bit. The organization is very heavily reliant on it as well to deal with security because the automation and it can provide across the ICD. And more automation means less manual touch points, where you can do things that help expose you to exploits. And then finally, what's not said here is dashed dynamic application security testing tools. So we have web application scanners first testing tools tools that are typically used when an application is in production, not during development. So that's another key category that actually ranks medium high from a standpoint of usage, but hasn't did actually show up in this particular question so I would make the case here that really a combination of SAS, SCA, DAST, and IAC is probably one of your best offenses from a standpoint of being able to be addressed security in a more effective way.  The interesting takeaway for me is, you know, the correlation here between the people actually using security tooling and having a security policy right. So, you know, that correlation and we've seen this in lots of other, in lots of other survey work that we've done at sneak. I mean, I think one of the most important things in this space really is about automation and, you know, embedding security tooling all the way through your software development lifecycle, you know, we have to move to this model of kind of for security and having developers have the responsibility and the tools available to them to fix stuff, you know, in the software development lifecycle. And I think we see this through this right, you know, we're using IDEs, tooling in IDEs, tooling in command lines, tooling in CI. And all these things have a slightly different, certainly different reasoning to use them at that particular point in the STLC but, you know, we did some work last year around the cloud native application security report. And, you know, for organizations with fully automated CI CD pipelines we saw much bigger take up of security tooling because it's easier to integrate when you're automating stuff already. You see a gigantic increase in time to fix. So, you know, these things have a real impact and I think if you're good at that automated deployment piece it becomes much easier to integrate security into it. Yeah, it's an interesting I think it actually it transitions over to one sort of the key takeaways mechs I think this that goes exactly what we're just talking about is the maturity of the ability to address a lot of these security issues is probably directly proportional to the automation associated with it's only what it's going to be the only way you can, you can scale it accordingly and so if we looked at, you know, knowing we're just about to the top of the hour of some of the key takeaways that I think, you know, are derived from from the information that was extracted and shared is there's a few approaches and I think one of these I picked up one of the questions that was queued up in there specifically around, you know, how do you how do you get me rephrase that how do you make sure that things are met and standard security processes and practices are in place especially with with DevOps and I think this aligns directly to that right so some of the key takeaways that I think you can derive from this report is involving developers in order to improve their security knowledge. So and that's a combination of you know, security awareness and training. So providing some of those details and guidance associated with why you're asking them to include that in there provided that opening up the common a little bit and sharing some of the details and insight and I think empowering them in order to actually make the decisions, most effectively and given the guidance on solving those problems can be extremely effective as far as improving your security posture across your organization. So hand in hand with that and what we just discussed right is is leveraging specialized security tools so as seeing sast I don't think you're going anywhere because they do provide some of that that guidance associated with and I think one of the other interesting this is inside the report which I will share the link to or the details associated with here just a second but one of the themes that that I think towards the end of the report that was also shared was a lot of individuals are looking at at vendors in the industry to help provide that guidance they know they can't take that burden on themselves there's a lot of sort of elements of of understanding security postures continuously and monitoring and looking for those risks and as we talked about a lot of those different sort of vectors of inspection in order to identify areas of trust can be very, very, you know, and daunting it if you were looking at doing it yourselves and so relying on outside, you know, industry and vendors and a lot of that that work for them and guidance and help solve those problems. And then kind of that last theme. And this is again we just we just touched on quite a bit was automated automated automated right that the, the only way that you're going to be able to address a lot of these security issues without impacting the speed of innovation is going to be embedding a lot of these types of things as early and often in sort of the development process and empowering sort of all of those members across your organization to make them security individuals make them or allow them to actually have a lot of the interaction and the ability to to make those decisions based upon providing that guidance and details and insight and feedback as early as possible but doing so that it works inside of sort of the approach that they use inside of your organization. So, with that said, here's last thing I'll use just to wrap up is the reports available there's a lot of additional details you can actually see in the screenshot there there's some summarize sort of statistics that we saw that more intelligence tools that I just mentioned is actually shared right there but then there's a lot of other additional insight that I think is extremely useful side of this report that you know downloaded and reading yourselves I think is extremely valuable wanted to think Steve is part of co authoring this report to because I think there's a lot of useful information data with that said I think there was one question. You just picked up on that I just wanted to answer the the other side of that question you'll be there which is, how should we consider the platform and DevOps side of security stuff well, you know, very, very briefly in exactly the same way that you consider your application code right I mean that that that movement, you know, towards removing manual intervention infrastructures code. Most are there among many, many scanners out there in the marketplace for scanning infrastructures code. And, you know, I think we've got this kind of emerging field of cloud security posture management, which is, is the sort of flip side to that of looking at your live environments and testing those live and comparing it back to what you had defining code so I think that's definitely the direction of travel. If you're not there already that's definitely where you should be going in terms of considering your kind of platform side of security just treat treat it like software development runs through CI gets scanned. Yeah, let me let me add something to this. So, adding to the conclusions. Number one, from the standpoint of developers and security professionals was more intelligence in tooling from vendors. And number two was higher level of reliance on best practices, when it came to security policy. And so I think to the to this question, I think best practices could go a long way to helping you understand from the standpoint of a framework for helping me understand where we are currently from the standpoint of best practices and use best practices, and graded or can't say the word but for the standpoint of, you know, things you should do versus versus follow a lifecycle essentially of best practices. Linux foundation has already built these best practices, go to open SSF.org, and look at best practices you'll see a course in there for secure software development. This was written by David Wheeler one of the industry experts in the space. There's about 150 best practices in total. You don't need to kind of try to, you know, eat the elephant one bite, but there's a course of certification, it's all free. And it could give you a great view into not only what you should be doing from an organizational standpoint and relative to what you've already done, but also understand from a perspective of how should we improve our security posture over time. It'll give you a lot of good ideas from a standpoint of what these best practices represent and what they do. So I think highly recommended as a way to help address the problem. Excellent. Thanks, Steve. Appreciate that additional insight. And with that, I know we're right. We're probably actually a little past. So Candice, I will turn it back over to the Linux foundation in order to wrap up. Thank you so much, Mick, Steve and Matt for your time today. And thank you everyone for joining us. As a reminder, this recording will be on the Linux foundation YouTube page later today. We hope you join us for future webinars. Have a wonderful day.


Hey guys, how are you doing? This is your boy Rich from Rich TV Live and you too can join the club at richpakesdaily.com where you can learn how to win and trade. Hi, how are you doing today? I'm your host Rich here on behalf of Rich TV Live with our very special guest, many time guest on the show, the CEO of GiveX Information Technology Group, Don Gray. How are you doing today, Don? Great. How are you doing, Rich? I'm doing fantastic. Very excited to have you on the show. Congratulations on all your success so far since you guys have been public. You guys have been moving up in really a tough market and in a choppy market where a lot of companies have struggled, GiveX has been a good quality performer. So congratulations on all your success, but I really believe that you guys are just getting started and I have a few questions for you. So Don, since you were on the show last, you guys have announced three pieces of great news. First one being gift card program with, I'm a huge fan of Maple Leafs, Toronto Maple Leafs and Maple Leafs Sports and Entertainment, Toronto Raptors, Toronto Blue Jays. And can you tell us a little bit about this deal with Maple Leafs Sports and Entertainment and this news and what it means for your company for GiveX? Well, Maple Leafs Sports and Entertainment is primarily starting off as a gift card client with some opportunities for us to grow that into loyalty and upticks. They are very similar to other clients we've got such in Major League Baseball and the NHL and where we've built a value-added ticketing program for those companies. And so it's a bit of a continuation of that. Obviously, we are very proud of being able to get Maple Leafs Sports and Entertainment because it's right in our backyard. That's a great brand for GiveX and we expect it to grow nicely and there's lots of opportunity within that group to be able to expand what we sell them. So obviously it'll be, we can start off with it's Maple Leafs Sports and Entertainment which kind of covers all of their brands. But we like to be going more specifically with more of the brands. But all that leads to, you know, that will take time. We have to work at it. But we're confident that once we got our foot in the door that we'll be able to expand what we do with these guys. So it means a lot to us to have a brand like that. And we're proud to have been selected and we had to compete in an RFP for that. And we were chosen over some good size competitors. Well, a lot of people don't understand that the Maple Leafs travel well. I mean, Maple Leafs Sports and Entertainment, you're literally working with a global brand because wherever the Maple Leafs go, they've got fans in the seats and it doesn't matter where in the world the Maple Leafs play, they always got fans in the seats. So I think it's a great move and I think it's just another step in the right direction for GiveX. Now, the second great news piece was the completion of the acquisition of Loyalty Lane Inc. Can you tell us a little bit about this acquisition and how another key step and how this is another key step in the growth of GiveX? Sure. Well, Loyalty Lane is a company that's been around for over 15 years. They're in, their focus is grocery and grocery couponing.  This is a program where they connect the companies that are supplying the coupons, such as big brands to people who are using the coupons, such as consumers, and they connect all of that right at the merchant's location, so at the point of sale terminal. So you're able to go clip your coupon, you can either do it physically with the old style coupons that we get maybe sent to you in the mail, or you can actually clip the coupons in real time on your phone. You can download them on your phone and you can then use those coupons at the cash register as you're buying product. And Loyalty Lane then gathers all this information and they are able to provide statistical information, both to the merchants and to the people that are supplying the coupons, the big brands as to who's buying and how often they're being used, whether these promotions are actually paying off or not. So we're quite confident that this is going to be a great acquisition for GiveX. They also have two subsidiaries, one is MSC, which is a company that specializes in building the websites and the apps that are used by consumers and by merchants to be able to use these coupons.  So MSC specializes in doing this. They've been a partner of Loyalty Lane for a long time and Loyalty Lane bought them about a year ago and so he became part of that group. So we're looking forward to working with that team because they can provide some of the expertise that we would need to be able to enhance our own capability on the couponing and that delivery of coupons to all kinds of different channels, particularly in the United States, which is a very big part of the program. And then of course, the third part of that acquisition was Electronic Script Pink, which this company has been around for 25 years. It was part of a bigger group and left, left alone really for the last five years, not much was done with it, but they have over 5 million people that have signed up for these ability to donate part of their purchase to their favorite charity or to their schools. There's over 50,000 schools and charities that are also registered on the platform, which gives us a whole bunch of eyeballs that we can then start working with when we talk about GiveX awards, some of the other things that we're going to be doing. So that's the overall Loyalty Lane, while not a big company, it has been profitable and we believe that adding GiveX's strength as far as being able to add additional development focus, development resources, we believe that this company is going to add a lot of value to the GiveX brand overall. I'm looking forward to it. Plus, they have about five and a half, six million eyeballs that are using their couponing program. So between the two, there's over 11 million consumers that we will have access to to be able to send promotional material to. And these are all opted in people that have opted in. So this is not like consumers out there that don't want to be contacted. These are people that want to be contacted. Absolutely love that. That seems like just an amazing, amazing deal. And you followed up with a third and most recent news you just announced, which I did a video on GiveX expounds iFood partnership to launch the iFood card in Colombia. You guys are now going to be in Colombia. Can you go through the partnership with us and how it's going to expand GiveX's footprint in Colombia? I know iFood has a huge footprint with you guys in Brazil. Now you guys are in Colombia. Let's talk about it. Well, iFood is basically a South American company. Now that they started in Brazil, they're going to be going into all the successful companies, successful countries in South America, starting with Colombia, and they'll be going to others as well. Great. Following them as they grow. But the concept is it's the same as we're doing in Brazil. We are able to, with the store value technology that sits on the iFood card that allows people to buy product and iFood has moved beyond just food. You can buy groceries, you can buy pharmacies, you can buy other things. It's just not a food delivery now. So it's becoming a wallet, almost a banking system in some ways for people that are unbanked in Brazil. That's why there's so many people using it. So it's become, and we earn a percentage on every transaction that goes through there. So as it gets bigger and bigger, it's more and more valuable to GiveX. So really Colombia is a small version of what's going on in Brazil. But it's the first of what we think will be many more steps into South America over the next couple of years with iFood. Congratulations on all of these acquisitions. I know you guys have worked really, really hard to build shareholder equity and create shareholder loyalty and build a quality company. And it sounds like all of these companies you're working with have been in business for a very long time. So you're not working with startups. You're working with companies that have reputations, have credibility, and have a large customer base. So before we go today, is there anything else you'd like to share with the investors that are watching today? Well, it's kind of a difficult market out there right now. It's hard to tell whether or not what's going on. The world is in a bit of an upheaval, certainly with what's going on over in Europe. It's a pretty scary time for everybody. So I think it's important that any investments that are being made are kind of secure. You're not taking too much risk. And I would say that GiveX is definitely a de-secured, a de-risked security. I mean, that's obviously my opinion. We're profitable and we will continue to be so well-capitalized. So it's in difficult times. There's a flight to safety and you don't want to stay away from risky bets. So I would think this is an opportune time for investors to look at companies like GiveX that are not as risky, that maybe are not going out there trying to dominate the world, dominate the marketplace with very expensive acquisitions that are just growing methodically and carefully. And that's kind of the message that I would probably like to give to our investors and potential investors is that you can count on us to be careful with what we do going forward. I like that. It's a safe play. It's an undervalued play in my opinion. A company doing over $50 million a year priced around $1 in Canada. I know we're looking at getting a U.S. listing soon. So we'll keep everyone updated on that. What is the best way for investors to get in touch with the company if they have any questions about GiveX? Well, we have an investor relations page on our website, givex.com. Probably the best place to do is go there. You can get lots of information on the company. You can obviously, on the website, it tells you more about what the company's doing. And there's an opportunity there to send in questions, and we will do our best to answer questions for our investors if they want to get more data or they can download information, download investor information from the website. Fantastic. Today you're watching the CEO, Don Gray, here on Rich TV Live. I must remind you guys, the Rich TV Live is strictly for information and education purposes. Please do your due diligence, do your research before you invest in anything that we talk about or discuss here on Rich TV Live. In saying that, we brought you guys GiveX first. We actually talked about it around $0.73. It's trading right around $1 today. I still believe it is undervalued, underappreciated, underexposed. Thank you for joining us today. The CEO of GiveX, Don Gray. Thank you for joining us today, Don. Okay, Rich. And by the way, we do have an analyst. It is now so we have an analyst tracking GiveX that's also on our webpage. So if you're interested in what they have to say, please have a look. Fantastic. Thank you so much. And I must let you guys know that if you're not winning, you're probably not watching. We bring you the winners and we bring them to you first. If you like the video, smash the like button, comment down below, share the video everywhere and subscribe. This is Rich from Rich TV Live with the CEO of GiveX, Don Gray saying, have a nice day, everybody. We'll see you soon.


This study investigates the effects of adding synth-sized iron oxide, magnetite, nanoparticles, MNPs, topolelactic, co-oaglycolic acid, PLGA, gelatin scaffolds. The MNPs were characterized using various techniques such as transmission electron microscopy, Fourier transform infrared spectroscopy, x-ray diffraction spectroscopy, and vibrating sample magnetometer analysis. The results showed that the MNPs did not have any significant effect on the morphology of the pores or the pore-sized distribution. However, they did increase the mechanical strength of the constructs and reduce their absorption capacity and biodegradation rate. Additionally, the stability of the MNPs and lack of iron release was the main reason for the success of this investigation. Finally, the evolution of rat bone marrow mesenchymal stem cell performance on the hybrid structure under a static magnetic field, indicated the potential of superparamagnetic constructs for future preclinical and clinical studies in the field of neural regeneration. This article was authored by Farnas Gorbani, Ali Zamanian, Alireza Shams, and others. We are article.tv, links in the description below.


and welcome to another episode of The Creative Life, a collaborative production between the American Creativity Association Austin Global and Think Tech Hawaii. I'm your host, Darlene Boyd, and joining me today from Los Angeles, California, are guests, University of Southern California Professor Dr. Sandra Kaplan and Purdue University Professor Dr. Julian Nyberg. They join me to discuss formulas to ignite innovation, problem solving and creativity in education and the urgent need to align creativity with future societal demands. Welcome to both of you, Sandy and Julia. It's my pleasure to have you with us today and hopefully we'll get a pretty good message out there. When Julia, when you were talking about proposing what we might talk about on the show, you took me back to thinking about the condition when Sandy, when I was working with you, things seemed to be pretty good for the advocacy for creative productive thinking in the classroom and outside of the classroom and in life in general, but something's taking a turn. And Julia, let's start with you. What do you think happened since this was your idea? I think the education paradigm has radically shifted since artificial intelligence hit the scene in November of 2022. And what we have in our classrooms is this idea that we're not only equipping our students with digital literacy, but we're also equipping them with a literacy that addresses artificial intelligence and the integration of artificial intelligence in knowledge acquisition, but also the production of content. And with the production of content and a new literacy that has entered our pedagogical discourse in our classrooms today, I think that we have this idea that it's not conscious enough to read and write using our standard literacies and digital literacies, but we also have to be in a space where we are producing creative output that is requiring us to not only learn, but also unlearn and relearn. And so we're placing our students in this environment where they're having to unlearn and relearn using a new toolset that all of us are being equipped with. Sandy, does that make sense to you? Yes, it does. But I think there's some other variables that do make sense to me as well, and that is that I think what's happened is the idea that standardization or measurement of what is success has somehow obliterated some of the issues related to being creative. And so we're looking at test scores that talk about how well you know something, not the many and varied ways you can use something. So that's one issue. The other issue is that I'm not sure that we have spent enough time helping our students understand at any grade level it's a dead leg to develop an appreciation for the art of creativity. So much of what they've experienced are really a consequence of creative endeavor. So while the students say, oh, look at this, look at this, I've got a new game, and they don't realize that that new game is really a consequence of somebody practicing the skills of creative thinking to really develop that game. So that appreciation for creativity is really kind of busy. And then the last thing I think is important is the fact that we've misunderstood that creativity doesn't need any one kind of learning situation. Children are creative before they even get to school. We just seem to take it away from them rather than enhance it. So those are three variables unconcerned. I think they're very important variables and I really think our viewers will appreciate hearing them listed in the manner that you presented them to us. Sandi, when I learned you'd be available to join us today, I was thinking back, and we usually start our show first of all by letting our viewers know that our guests generally take us through the processes behind creativity, the creative process, or they take us through their real-life creativity. And you two are both the icons of creativity in many ways to me. But as I was thinking with enthusiasm that you'd both be joining us, Sandi, I was thinking of something we were somewhere many years ago, very informally. And on the show, we usually always am reminded that we need to clarify the concept of creativity so that our viewers can understand in what direction we're going. And someone had asked you, and you did an off-the-cuff, they asked you how you would define creativity. And I don't know if you remember this little casual definition, but I use it all the time, and it means a lot to me. And you define creativity at that point, and it's probably a restaurant conversation where you said, well, we look at something and we break that something down into its parts, and then we reconceptualize it into a new thing. And at that time, so many people in the discussion were thinking that with creativity, you have to experience that aha moment. But your definition was a little more sophisticated to be it also very practical. And that it doesn't, we always, we don't always have that aha moment. But if we know that we're going to take something, it doesn't always have to be a totally brand new idea. But it does seem to be a new idea because it's different after you put those parts together in maybe a different way. One of the things I think about, and I certainly, Julia, can add to this, is the work that Everly did years and years ago when he identified the scamper techniques, the skills of creative thinking, and I don't want to go through all of it, but just think about this. His conversation about and his work in relationship to creativity said that creativity is being able to add something to something that's already existing. It doesn't have to be the formulation of a whole new. It's what can you add to it, bringing purposes for a new insight. He also said that creativity is the ability to look at what happens if it gets smaller, what happens if it gets larger, the minimization or the maximization of something. And then one more, that creativity is really the ability to be able to understand how we combine things in order to be able to get something new. And I thought about this and I thought, you know, this is what young children do. As I watch in the preschool work that I'm doing currently, students do this naturally. They put these together and go, ooh, are they taking for part and say, oh, wow, look what happened? What can we do to make creativity a more natural consequence or behavior rather than an artificial type of lesson that sometimes is produced in a school-age study? What can we do, Julia? You talked about unlearning. That was an interesting way of stating that we usually lock in on learning and not unlearning all the time. So help us out a bit here. Well, I think the reason why I started by anchoring the conversation in examining the tools that we currently have to work with in the classroom is because a huge component of creativity is our environmental factors and being open to new experiences. So by being open to new experiences, we also have to engage in this new toolset that we have to equip students with. And that is the literacy skills associated with artificial intelligence and embracing the ambiguity in that type of product production, that type of innovation that we currently have to work with. And I think if I was a classroom teacher and stepping into the classroom this fall, I would be most interested in linking both inductive and deductive reasoning in my instruction. And deductive reasoning is the strategy that I would use where I would have my students develop ideas from something very general to something specific. And inductive reason is the opposite, where I'm having my students take something specific and then further generalize it. And I think the reason why those are so important in relationship to creativity is the fact that this process of being able to generate ideas and innovate both inductively and deductively is important because we're able to, I think both of those are able to play an essential role in not only the process of problem-solving and critical thinking, but also to creative output with the new tools that we have available for our students to use, not only today, but also for those jobs that we don't know we're preparing them for yet in the future. You just referenced critical thinking, and that raises another question for both of you. It often comes up in some of our conversations in previous shows when we talk about entrepreneurship and innovation, and that is, do you think one can think critically without thinking creatively and can one think creatively without thinking critically? And I know we've talked about that before. I think I'll hand in hand. I mean, in order to really be innovative in order to be able to redesign something or to really look at how you're going to add to it or substitute one thing for another, you need to be critical. You know, is this going to work? How is it going to work? You have to make judgments about, you know, what ambiguity you're going to face and what logic you need to make sure that it will be something that's useful. But I think there's another part of this, and that is that I think one of the things that we're talking a lot about is the idea that we need to reconstitute the concept of play and to be placeful. You need the attitudinal reference in order to be creative. You need to be willing to see that it doesn't have to be the right answer. There are many barrier and possibilities. You need to be in the ability to kind of deal with ambiguity and you need to be able to really be patient to see how things emerge. So how do we develop more of an excitement about being playful? And I'm talking about being playful with ideas, not just with, you know, things. Well, how do we really help individuals understand that that playfulness is really one of the stimuli that really does, in fact, excite? Critical and freed. Juliet, in your work, I know that you reference collaborative thinking and risk-taking. But while celebrating mistakes as opportunities and Sandy's talking about being playful and Juliet, could you talk a little bit about the mistake, the concept of tolerating mistakes and the outcomes from that process? Well, I think that circles back to the conversation that Sandra Kaplan contributed regarding our measures that we currently have in the education system for accountability. Our measures of academic achievement are based on the premise that there is something right and there is something wrong. What does that teach our students about the concept of mistakes and play? If I'm playing in science, for example, if I'm generating new ideas, if I'm innovating in science, if I'm being creative in science, does that necessarily mean that I'm going to generate a right answer the first time? We think about devices like our smartphones sitting near us right now. The development of the smartphone was a process that had a lot of mistakes along the way. For example, if you think of Steve Jobs and the development of the Newton, does anyone remember the Newton? Probably not. If you look at the initial specs for the noon, it was exactly like the iPhone today. It just wasn't adopted because the infrastructure wasn't there yet. So now we're equipping our students to produce to the innovators to be creative thinkers in this environment where the infrastructure has changed. And because the infrastructure has changed, I think that we need to rethink creativity in relationship to our interaction with our children and students. Sandy, how do you suggest that we might rethink our creativity? I think that one of the things that we really need to look at is the idea that creativity has both formal and informal elements to it. So there are wonderful creative things that are part of my surroundings here that somebody has developed and I have privileged to be able to have in my home. But there are other things that are creative that we don't give a lot of respect to or a lot of credence to. The idea that somebody comes up with a new recipe of doing something that is traditional and maybe adds just another little flavor to it. That we need to look at creativity in its small as well as in its larger context. And we need to look at it as a way of thinking, not just a way of producing so that we can talk about the fact that in our interaction with each other, I could come up with a new idea but it may not go any further than just our conversation and that we can appreciate the idea of creativity as a way of interaction, not just a way of production. And then one other thing that I want to say and it really supports what Julia was saying in terms of schooling. That is I worry about the fact that to have the opportunity for creativity you need to be in the environment where the people that are teaching you instruct you, working with you also value the same thing and that's creativity. That you don't have to fight quote-unquote the idea of coming up with a new or an original idea with somebody saying well actually proud to come up with that and deleting it. We need more teachers, we need more parents who are receptive to the many and possible responders to an idea, to a question, to a problem, to a situation. I think in terms of your commentary regarding creativity associated with production I think we also need to value creativity as a form of production and incorporate creativity into our accountability system within education. I think if creativity and innovation was valued as a means of production and not a standardized test being the means of production we would have a different degree of that informal creativity that you speak of. But one other thing I'd like to just add to that and that is that it's not my idea that it goes back to Prybel and Rousseau and Locke and others who said that if you just look at students young people, they are creative. Why is it the older they get the more creativity they lose? And so what are we doing to really excite an appreciation for creativity? How come we're not spending more time sending our children to museums to see the creative production of others? I think it's something on television. We don't just look at the storyline. Look at the creative aspects that came into developing the story. So we need to develop more of an appetite for what creativity is now it's all around. And I think that's what we need to unlearn. Oh, understandably now. You're both advocates of the importance of knowing how to ask a question. You're commentary just now. And I think so many of us don't think through the questioning that we might be having. Then there was a question you just asked, like, why aren't we doing something? Why aren't we asking more questions? Why don't we have more interaction? Well, because just what we said earlier, everyone's on their phone and we really do need some time out from that. I'd also like to address the idea of problem solving and clearly it seems that it's very, it would be near impossible to find a creative process that didn't take us to a problem or some discussion with problem solving. And I suspect you would agree with me that often the correct problem is not the one that's brought forth to solve. Or there's not that vision to look at the consequences of solving a particular problem. And we see so much of that with a discussion of climate change and some of the recommendations that just running into a situation and thinking that we have identified the problem and it's such as not the case. What are your thoughts on that? I think that certainly, you know, Julie could add to this. I think that one of the problems is that we don't venture into problem solving because we think we need to have a tremendous amount of information to be a problem solver. When I think of the work of Trustee Ger and others, as you well know, Darlie, have taught us that you need to have the questions to ask. You don't need to walk into problem solving with the answer. You need to walk in with the question. And I think we kind of in some ways diminish the value of questioning, as you mentioned earlier and really look at, you know, let's get the answer, let's get the answer rather than let's travel the road of many and varied questions. And maybe the answer will come up. But in the process, there'll be many kind of ways in which we can at least understand the problem better by the questions that we ask. I think we probably, I think you two might agree with me that we're sometimes irritated when we are working with, and this is more often outside of education more in the business world where you'll hear someone say, let's just brainstorm and they think they've gone through a very creative, productive method when in fact brainstorming is just one of the steps in getting through the process. And not to say that there is an ignorance, but there is, I don't think, and probably ourselves included, we've not done enough to really communicate what's necessary when we're working with groups, when we're even in a church situation with a pastoral group and trying to solve whatever the scheduling kinds of things. So even taking it outside of the educational area. Before we do run out of time, I'd like both of you to talk a little bit about what you think are the barriers that are in our way to really promoting the idea of creativity, bringing it back to its paramount days in the educational settings. And we did talk, we have talked a little bit of the barriers, but what do you think are the major barriers that really get in our way right now? Well, I think that both Julie and I concur that standardized testing and looking for the right answer is when. But I am concerned about the fact that we haven't developed a real sincere appreciation for creativity. I am concerned that we haven't looked backwards to see that throughout time. What we enjoy today is the consequences that people's creative expression yesterday and that we're not giving enough credence to the fact that it's creativity that got us to where we are today. We make an assumption without giving, I think, tribute to the creative process. And I think one other thing that we've mixed up, and this is, I take full responsibility for this comment, that we've mixed up creativity and economic gain and they don't necessarily go together. That you could be very creative with the pleasure of being a creator, not necessarily for the economic gain it might derive. Hmm, very true, very true. Julia? I think one of the biggest barriers in the education system is the fact that we have compartmentalized and separated academic disciplines. If we enter the classroom or the learning space within interdisciplinary lens where we're looking for the connections between and across and within content areas, that we would produce a much more creative student population who was willing to engage in informal creativity and create for the pleasure of creating because once you engage in interdisciplarity in the education system, then you have the ability for students to make connections between things that are unconventional, that may not be obvious to the adult teachers sitting in the room. And I think that is perhaps one of the largest and easiest barriers that we could tackle as parents and educators. Well, I agree. How many schools and universities play a role in cultivating a generation of innovators? Which professor would like to take that? I think it's a real dilemma because one of the things that universities are trying to produce are people to go into the field and have the prerequisite understanding and skill they need to be part of the field that they're going to enter. The other part of it is how do we produce people to go into the field who are change agents who do understand that while you need a certain basic understanding for the field, you also have the tenacity, the skill to be able to really see where you can push and shove to make differences. So it's an interesting balance. And I think all universities try to produce people who can do a combination of teachers. And to know the academic understandings, the skills that are necessary, and to have the understanding of the importance of using those in new and different ways to improve whenever that field might be. What's so interesting about the K-12 on university space is that it often provides the template or the expected environment for learning for all other fields. So I could be working for AT&T and I could be providing training for all of my telephone operators at AT&T, providing that training and that experience that those individuals have in training is often from the experiences that the trainer had at the university or in the K-12 setting. So it's really up to the K-12 and university setting to reconceptualize what schooling looks like. Because the experience that individuals have in their own classroom often informs how they teach others, whether that be formally or informally. So if we start giving students different experiences in regards to our expectations for informal and formal creativity, utilizing things like inductive and deductive reasoning to generate creative solutions or generate questions associated with the environment that we're interacting with, that would in theory have a, I think, domino effect across all types of learning experiences. I think you would both agree that there are a number of package programs out there for the creative process. And I think it's important that we be selective and some of my favorite programs are those that clearly take us from the creative to the critical and back and return us so that we are doing a technique such as brainstorming and then our next step is going to be bringing us back into the creative process, thinking very critically. And as you referenced, Julia, throughout our conversation this afternoon, you've been referencing deductive and inductive reasoning. So yes, those models that do take us inductively and deductively as we are leading us to solve a problem of some sort, whether it be a lofty problem or a made-up one for demonstration. So I think that's important for us to also remember. And then also to remember that you can't be creative about nothing. You can't turn to someone and say be creative. You need some context or something of some sort that the process matches. So any concluding remarks before we depart for the session? Yes, I'd like more individuals, broke children and adults to walk around the world with maybe well, the world. A pen and maybe a piece of paper and to list all the things that they see that have been a consequence of creative endeavor. I think that we've lost track of how much we are immersed in other people's creativity and the results of their creativity. I think we need to develop a greater respect and appreciation for the fact that much of what I experienced is the consequence that somebody else has created. What a simple meaningful exercise. That's a beautiful exercise not just for children but for adults as well. I can think about that myself as I move around in different places. Julia? And on that list you could look at each of those items and think to yourself has this item been developed as the result of a part-to-whole relationship or a whole-to-part relationship. What is the connection between part-to-whole or whole-to-part in relationship to this creative item? And how can I begin in my mind to deconstruct that in connection to that creative evidence that you find in your world? Beautiful framework for us to conclude with just lovely. Thank you both for joining us this afternoon and I look forward to speaking with you again and hopefully having you return time to time so our viewers can enjoy the wealth of your wisdom. And with that you have been watching The Creative Life on Think Tech Hawaii with guests Dr. Sandra Kaplan and Dr. Julia Diber as we discussed just empowering minds and infusing innovation and creativity in educational and real-life experiences for students of all ages. Join us in two weeks for another episode of The Creative Life until then mahalo and aloha. Check out our website thinktechawaii.com mahalo