Announcements

Between mid-October and November, the content on AREA will be relocated to the Autodesk Community M&E Hub and the Autodesk Community Gallery. Learn more HERE.

Security best practices in open source

It’s cyber security month, and I sat down for a conversation about security best practices in open source software with two of my colleagues – application security engineer Amrata Kasture and tech evangelist Aliza Carpio. Security in open source isn’t always talked about but it’s critical to ensuring “trust” and confidence in open source software. Here is a recording of our conversation and a summary of the ideas we discussed. My hope is that it inspires you to learn more about security best practices in OSS.   

--- Alexis Womble, Cyber Threat Intelligence Engineer 

 

 

 

 

Aliza: Hello, Alexis and Amrata. Thanks for taking time to meet with me and share your stories, lessons learned, and guidance on best practices in security within the open source space. I'm so delighted to chat with you. 

 

Amrata: Thank you for inviting me. 

 

Alexis: Yes, thank you.  

 

Aliza: Thanks so much. Before we get started, I'm going to ask each of you to introduce yourself, your role, where you're located today, and just for fun, what do you consider to be your hidden genius? 

 

Amrata: Sure. I’m Amrata and I have been with Autodesk for five years. I'm with the application security engineering team and I’m based in the San Francisco Bay Area. 

 

And what’s my native genius. That's a tough one. I feel my native genius is in dividing any problem or any issue that comes in front of me into small things and approaching them one at a time. 

 

Aliza: You also have something in addition to the breaking down of the problem set. I also think you're great at providing guidance. I'm just going to add that to your native genius. 

 

Alexis, let's hear from you. 

 

Alexis: Well, first off I want to partner up with Amrata for the rest of my projects, because it's something that I know I need to do every time, and I sometimes do, but I would not consider that my native genius. So, I'm definitely going to need your help, Amrata, in the future. 

 

I'm Alexis. I currently live in the Boulder Colorado Area. I am a cybersecurity threat intelligence engineer. I would say my native genius is being able to take more complex security things and explaining to them to the common person who's not in technology, on a level which they can understand, and applying that to the real world. I love metaphors so definitely a lot of metaphors. 

 

Aliza: Alexis, I love what you said. Having worked with you and partnered with you, I can also say that you are actually very good at crystallizing what's happening in a very succinct way. 

 

That's something that I wanted to throw out there as well, because I do think that's something natural for you. So, I love learning about people's native genius because I think it's a hard question and it makes people think about that. And I think you all should own that native genius. Thank you for sharing that. 

 

Now let's jump into our chat by defining first what is open source. And again, this is for those who are not familiar with the term. So Alexis or Amrata, please share your thoughts and would love for you all to riff as well. We'll start with Alexis. 

 

Alexis: Honestly, I wish I would have given you the Google Answer, because I feel like I'm going to butcher it. But, I would say in my own words, that open source is something that a company puts out there, or an individual puts out there on the Internet usually. Then anyone can use it, anyone can contribute, and make it better. Short and sweet. 

 

Aliza: What would you add, Amrata? 

 

Amrata: Yeah. As Alexis mentioned, it is as the term itself implies. Open source is something open for viewing and open for contributing. But not only that, it’s also open for distribution, and I think that brings the most value. We often relate open source to open source software, but anything can be open source, such as in different domains like open source journalism or open source movies. A fun fact is that there are open source “colas” there where people contribute to a soft drink recipe.  

 

Alexis: I love that reference. Again, I love metaphors, so when you say like an open source recipe, it's a bunch of cooks in a kitchen making up an even better dinner. One does like the entrée, one does the appetizer, and one does the dessert. Everyone contributes to an amazing dinner. Plus, I love food, so it’s a perfect metaphor. 

 

Aliza: Food always makes it somewhere, right? Now, today we're going to talk about security best practices in the open source space. I want to start with you, Alexis, and then, Amrata, please do add. When we say “security best practices” as a phrase, what is meant by that? I think it's something that can seem high-level. I'd love for you all to break that down for us. 

 

Alexis Womble: Yeah. If you don't mind, I'm going to keep it higher level, and then I'm going to let Amrata build on that if she wants to, because our last one sounded amazing. So thank you for all that added input. 

 

We could literally break down the term “security best practices” word by word, so it's all about, security keeping your information secure. Something that is especially important is PII – personally identifiable information – which is like your phone number, your email, your name, your date of birth, your social security number if you're in the United States, your address. Stuff that’s important to you. But obviously it goes past that - anything that we're trying to keep safe, any data that could be company secrets at Autodesk. There are a lot of different things we need to keep secure that we don’t want other people having. So that's the security part. 

 

Best practices come into the coding. When you're building an application, how should you build an application with security in mind. Without even thinking down a rabbit hole of security, best practices are like guidelines. Like hey, we might not be able to make this perfect application. (No one makes a perfect application the first time!). But if you implement some of these best practices, then it’s going to be more secure than a lot of things out there. There's a lot of stuff that's not secure. In a roundabout way, that's how I would describe it. 

 

Amrata: Yeah, I agree with Alexis, and just to add to that I think as a company Autodesk has come far in these years when it comes to following the security best practices. The company gives many platforms where teams can keep up with the security best practices as well as coding best practices. These best practices help keep the products both secure and maintained over their lifetime. 

 

Aliza: Thank you both. Now we've defined open source, and we've also defined security best practices. With those two terms, I'd like to learn from both of you what are some of those best practices that we, as open source contributors or maintainers, should know about? Whether you are contributing to projects sponsored by Autodesk or not. I'd love to have you share stories or case studies from which all of us can learn. I’m going to start with you Amrata. What are some best practices that we should know about in open source? 

 

Amrata: In my opinion, maintainers do own that extra responsibility as opposed to contributors when it comes to open source. Here are a few things that every maintainer should have on their top list. First, they should document. They should talk about everything such as - What are the expectations from the project? What is the scope of the project? What kind of contributions are they welcoming. And they should be responsible for the changes that they accept from the contributions. They should be very well aware so they do not merge any unintended or  

non-standardized pull requests. They should be looking for any vulnerabilities introduced with the pull request. They should take seriously the security bugs, or any other bugs, reported by the contributors or the users of the open source. Offer the estimated time for fixing bugs to users. I think these things are very important. 

 

As contributors, one should contribute as a responsible citizen of the developer community. They should be respectful of the scope of the project defined by the maintainers. And follow the standards which are outlined by the maintainer of the repository. These are the few things which I think are top for any open source software. 

 

Aliza: I love that you mentioned documentation. It's probably one of the most important things to really think about and consider. Alexis, what would you add to what Amrata just shared. 

 

Alexis: Yeah, I love all of that. When I think of security best practices, especially within open source, there's a lot that goes into it. It's hard to give you a top five or a top twenty even of best practices. There is a lot of content – you can google it – that ties to that, and they're probably missing something. But I would say that it is probably a bit more of the person who is maintaining the code that’s important, like Amrata said. 

 

But also remember that we live in a world where security is not going to go away. Everyone takes security training. Everyone hates it when they receive an alert about a breach. Everyone hates phishing emails, but it's something that's never going to go away. I think we need a change: To not think of coding and security best practices as separate but that they merge and go together.  

 

I would also put the human aspect into it. It's been a long time since I've coded anything. But when you’re in your line of code looking at everything, you may not necessarily be thinking of the consequences or the humans that are going to be using the code. Remember to think about that code from an attacker standpoint. Again, this might be just my job description because I like to look at the threat intelligence, and that's like threat actors and people who want to harm, take our information, and use it against us. What if you are the user? 

 

What if you're on the other end of that using it? What do you want to make sure that's protected? And how do you protect that? Because you're the coder, you're the person who's going to maintain the code, it's important for you to think about the human element - Not just how do I want to make this pretty or how do I want this to work.  

 

Aliza: Well said. Now, I know both of you said that there are many best practices and the list goes on and on. It's a long tail. But let's just take the scenario that I am a new maintainer. I just launched this open source project or I’m about to launch an open source project. Are there one to two things that you recommend should not be compromised? Is there some low hanging fruit I should not miss as someone new to maintaining an open source project? 

 

Amrata: I can share some but I will exceed your one to two limit. One is, of course, document. That is a no brainer. Only when you document, will you receive well formatted contributions.  Second is to release secure and good code, so that others can follow your same path line when they contribute. And third is to use the technology – run scanners on every pull request so that your work is easier as a maintainer. And only merge the pull requests that comply with your standards. 

 

Aliza: Well said, Alexis, would you add anything? 

 

Alexis: I agree again with everything that Amrata said. I would add again to look at the human element,  even something as simple as password management. When you're building an application and you put it out there for people to look at the code, there will be someone who wants to break it unfortunately. And sometimes it’s hard for us to find the bugs in our own code. It's just how it works. If you have anything that has to do with authentication, or if you're putting a username and password, make sure you're keeping it protected. I think that's like my number one thing, especially personally identifiable information – all that sensitive data. Make sure it’s encrypted. Make sure it's clean. 

 

Aliza: Thank you both. So here I'm asking you about what are the best practices that we can all employ. On the flip side of that, what are the risks or gotchas when we don't? When we decide “I'm not going to do any of that.” “ I'm just going to ignore it.” “ My project isn't that big of a deal anyway.” What are the risks or gotchas by not employing best practices? 

 

Amrata: I can go first, so I feel that if you don't apply, then you're defeating the whole purpose of making open source. Any owner of the open source would want to invite more and more quality contributions and grow their user base. But when the quality starts going down, then the users start to go to alternative sources, and you lose out on good contributions.  

 

In my opinion, this will reduce the lifetime of your open source software and weaken your reputation. There is a domino effect. If one of your open source software projects has a reputational risk, then your other contributions also get doubtful eyes.  

 

Aliza: So reputation is definitely huge. Like you said, if I was to release another open source project, people are going to say, “Oh, I remember that person and their work”. Alexis, what would you add to that? 

 

Alexis: It'll impact anything else you do. But it also might impact anything that your application is dependent on, or that you're dependent on for your application or your code. There have been countless examples - huge examples of places who let’s say got ransomware and it spread to all their customers. This wasn't open source necessarily, but you can imagine Open source is even bigger so the possibility of it spreading is a lot worse. 

 

Amrata: I think you will remember examples where the open source software was not famous before the exploit came in the picture. 

 

Alexis: Yeah and just knowing what you have. If you're maintaining a lot of code, and you're an amazing developer who just keeps coming out with stuff, you might lose track of something that's a bit older. You might not even think about it when a new security vulnerability comes out. Don't forget what you're maintaining. Because it's old, you still might need to patch and update certain things about it. Update, update, update! 

 

Aliza: Exactly, applying those patches is part and parcel of delivering code or solutions out there. I learned so much from both of you. But I want to ask you if I am someone looking for these best practices, do you have any specific resources online that you would suggest I check out? I'll start with Amrata, then Alexis on that one. 

 

Amrata: One that comes to my mind is open source security foundation blog. I think that is a good place to learn what is happening in the open source security world and explore initiatives that your teams can leverage for your open source projects. 

 

Alexis: Yeah, there are a lot of resources out there. Documentation, documentation, documentation like Amrata said. I think OWASP  if you're doing something specific for web applications is a good one. They offer the top ten most common vulnerabilities for web applications. So that can give you quick insight into the top to mitigate or at least think about. 

 

There is also NIST , which gets into more of the security side. They have a lot of documentation for security, even going outside of open source. If you're interested in other things that go along with your open source project, NIST is a good resource on best security practices. 

 

Amrata: OWASP has an open source specific security chapter. 

 

Aliza: You're both so knowledgeable in this space, and I really appreciate learning. Now, I'd like to switch things up and talk about you and your role. So I'm going to ask you to take a moment to think about it, and I'm going to start with you Amrata, what do you enjoy about being a technologist in security? 

 

Amrata: I was introduced to security during my summer internship at Autodesk. I was a web developer before, but this was an entry gate for me in security. I enjoyed being part of the security domain. I feel like I found a home. About being a technologist, it's the impact I can have where I help make product teams be more secure by having security scanners run on their source code and remediate issues. That’s what I enjoy most in my current role. Also, it feels great to continue to improve the security posture of Autodesk products over time. 

 

Aliza: Alexis, what about you? What do you enjoy about being a technologist in security? 

 

Alexis: I think half of it is that technology and security are ever evolving. It's not the same problem as it was probably a week ago, a month ago, or even sometimes a day ago. There are always new things coming out, especially in security. There's always someone being attacked or hacked unfortunately, but it keeps us busy, especially as new versions of things come out. I think I really relate with what Amrata said about purpose, and yeah, keeping people safe. 

 

Aliza: Well said. On a related question, for those who are rising seniors at university, or thinking of switching to a career in security, what advice would you give them? I'll start again with Amrata. 

 

Amrata: I’ll say just go for it. There's plenty of space as Alexis has just touched on. With such fast-paced changes happening in technology, I think there is a lot of space. And especially for my women colleagues, I think there is way more space. So just go for it. 

 

Aliza: Thank you. Alexis? 

 

Alexis: Yeah, go for it. We need more people. We need more women. We need people with other backgrounds and how they think about problems differently. 

 

I've always said this to interns. At one of my internships, there was a guy who was probably in his 30s and who worked on fossils, something along the lines of paleontology, and nothing related to technology. He wanted to change his career, so he went back to school and got his masters in cybersecurity. He is one of the best cyber security analysts that I know to date still. 

 

There was also someone at Autodesk in sales who came over and did a rotation with us in security, learned so much, and aced his “Security Plus” exam at the first attempt. That’s a hard test for people. Going from a sales job, which can be the same thing day and day out, to technology where no day looks the same, I think was exciting. It’s certainly exciting for us. 

 

Aliza: Thank you both. I'm going to switch things up again. We are now at the rapid fire portion of our chat. This is just for fun. I’m going to ask you all a series of questions. You are going to tell me whatever comes top of mind. These are totally not hard, at least, I hope they're not. Are you ready? We'll start with Alexis. 

 

Okay, Alexis, if you were a tree, what kind of tree would you be? 

 

Alexis: A willow tree because I think they're very pretty and inviting. You don't snuggle with it, but it's kind of snuggly. 

 

Aliza: Amrata, what is your favorite breakfast food? 

 

Amrata: Fruit platter. 

 

Aliza: Alexis, where do you plan to travel to next for fun? 

 

Alexis: I want to travel everywhere in the entire universe. But I think the next place will be Japan. 

 

Aliza: Amrata, what’s your favorite place, local or not, to unwind and give back to yourself? 

 

Amrata: Undoubtedly, the Muir Woods. 

 

Aliza: And then for both of you, what the one thing that you want to leave the readers with as it relates to security and open source? We'll start with Amrata and then Alexis. 

 

Amrata: It's worth having software as open only when it’s secure. 

 

Aliza: Oh, nice! Alexis?  

 

Alexis: I love that. Be open to security and be patient. 

 

Aliza: Wow! Both of you, thank you so much for spending time with me chatting. It's a rap. 

 

Folks, do take a moment to check out Autodesk's open source site and our careers site for tech roles. Until next time. 

 

Alexis: Thank you. 

 

Amrata: Thank you. 

 

About the contributors...

Alexis Womble is Cyber Threat Intelligence Engineer

Amrata Kasture is Lead Application Security Engineer

Aliza Carpio is Director, Tech Evangelist