The Slack Internship — Matt’s First Time at Slack
I’m Matt and I’m a senior Computer Science student at North Carolina State University in Raleigh, NC (Go Pack!). In my free time I enjoy traveling, hanging out with friends, discovering new music on Spotify, running, and hiking. I’m also a self-proclaimed sushi enthusiast.
Coming to Slack, I was excited to be working at a company whose product I used so much. From when I first walked into the building, everyone stood out to me as friendly, driven, and excited to be working here. The first week mostly consisted of on-boarding and meeting my team and other interns. I found on-boarding to be well-organized and informative. We had a dedicated Engineering on-boarding that showed us how Slack deploys code and an interactive session about Slack’s human-first, feedback-driven culture.
Besides the people, one of my favorite parts of working at Slack is that, internally, we’re Slack power users. Before coming here, I used Slack for communication, but it’s capable of much more: code review workflows, interaction with tickets, and notifications for visitors and deliveries are just some of the ways we’ve integrated other tools into Slack, as the centralized hub.
Another part that I loved was the creative freedom. When I arrived, my team gave me a problem, and I was able to architect and develop my own solution to reach the desired impact. I had the freedom to create my own solution, but the support of an experienced manager and mentors providing feedback along the way.
Back to Slack — Ryan’s Return Internship
I’m Ryan Slama and I’m a senior at Cornell University. I enjoy small concerts, hot beverages, and home-brewing beer. I’m always up for a modern board game or interesting discussion. Returning to Slack was a bit of a shock because the company had grown by around 40% in the nine months I was gone. All but one person on my team had joined Slack since I had been there last. Initially, I was worried because the excellent people I worked with last year were a large factor in my decision to return, but those worries proved unfounded; I found myself surrounded by a supportive, kind, and knowledgeable team. As a junior engineer, finding strong mentorship is pivotal. I’ve found that I can reach out to almost any engineer and set up a time to chat. This alone has helped me grow by exposing me to new perspectives on engineering and life in general.
Additionally, using Slack at Slack has also been transformative. I can jump in to any team’s channel and see what they are working on, as well as future plans. Watching other engineers solve problems helps me learn faster and gain experience more quickly than I have at other companies. For example, reading the history of #pwl-slack, a channel inspired by the external Papers We Love movement, helped me learn about cutting-edge papers in computer science. Through this channel, I was exposed to ideas above and beyond what I’ve done in school or as an intern project. I had the opportunity to attend the small group discussion on the Zanzibar paper alongside top-notch engineers, which proved to be a great learning opportunity. Slack’s transparent culture has empowered me to learn faster than I could otherwise.
Making an Impact
We joined the Product Security Foundations team, which decreases Slack’s risk surface by developing new libraries, tools, frameworks, and services. It establishes a comprehensive and innovative approach to security while enabling safer development of new features and services.
When we got to Slack, we were given a problem: Slack wanted to do a better job auditing our use of external dependencies for security vulnerabilities. This problem is one of the OWASP top ten most pressing security risks, listed as “Using Components With Known Vulnerabilities.” With Javascript and npm in particular, requiring one package often means adding an entire tree of packages to your project. Our main repository alone contains over 3,000 dependencies in Javascript and Hack. Slack is no exception here; this is normal for modern frontend apps and we have many in our largest repo, which contains the code for our web client and our API.
Solution
We started our project by building towards an MVP: detecting vulnerabilities in Javascript/npm packages with daily scans. We wanted to detect any newly discovered vulnerabilities, track their status towards remediation, and notify owners. We chose a tech stack using modern technologies and best practices like React hooks and Typescript. When we reached MVP, we could collect real usage data and feedback to better understand how to provide value to our developers.
The first thing we learned was that while we were providing visibility, it was hard to act on the information discovered. We require packages in a number of files, so knowing where to start looking was difficult. As we added support for Hack and Go, the app displayed vulnerabilities from multiple package managers in the same list. We started to track files to help identify ownership in large codebases and make remediation possible.
Our next discovery was that the majority of vulnerabilities were not in our direct dependencies, but rather somewhere deep in the dependency tree. Fixing vulnerabilities required manually reading npm lock files and following long trails of package entries. To this end, we created a force graph that shows dependency relationships so that we can easily identify which packages we require directly. Here, the package with the vulnerability, is-url, is shown on the far right. We map dependencies to find which packages we actually require, then show those in bold. This empowers developers to fix findings with minimal effort and wasted time.
Results
We presented our work to the Product Security organization every other week during playback meetings. Demoing regularly allowed us to get feedback and iterate faster. We later presented to the entire security team and hosted an open Lunch & Learn to get buy in from the rest of engineering. With our dependency detection tool, we’re able to catch vulnerabilities throughout our code quickly, making the Slack product more secure. We’re also able to provide visibility of open source usage risks to the Product Security team and service owners.
Retrospective
Looking back on our project, we identified a few things that we wish we had done better. Our initial data model wasn’t scalable when we started adding new features like modeling package relationships. We could have avoided replicating work by modeling logical objects and not using the simplest sufficient model to reach MVP quickly. Additionally, notifications would make more sense if they could be tied to specific files rather than repositories; this would help in cases where different teams are responsible for different parts of a codebase. Finally, the signal to noise ratio is low, and many findings that we record as vulnerabilities are not actually dangerous to production code. For example, some packages are just used for testing before deployment. We only pass known inputs into this code and never run the code with customer data. This means those findings do not pose a real risk to Slack’s security, but migrating away from some of those packages may be a significant engineering effort. Filtering signal from noise and finding effective remediation strategies remain for future work.
Special Thanks
We wanted to give a special thanks to our manager, Suzanna Khatchatrian, and our two mentors Fikrie Yunaz and Oliver Grubin for supporting us during our internship and making summer at Slack great.
Can you help Slack solve tough problems and join our growing team? Check out all our engineering jobs and apply today.
