Building values to love your team

I love my team. I go home and say it out loud nearly every single day. Yes, some days in a startup are frustrating - a sale might go poorly or we’re set back on an engineering timeline, but by the time I leave I have a solution and it’s often because my team works together to come up with a unique way to solve any problem.

I started Tinfoil with the explicit goal of learning something new every day. Some days I learn much more than other days, and the few days I don’t learn something new it’s always my fault. I thrive off of surrounding myself with individuals with a similar drive, especially when all come from very different backgrounds and experiences. Every founder I’ve met has a different goal: some want to learn new things; some want to become famous, or become rich, or change the world, or invent. An organization’s blood is determined by these early goals.

A mismatched employee at the early stages will slowly affect everybody. Somebody has to not only be a fit for Tinfoil, but Tinfoil should also be a fit for them. To help any prospective employee understand us, we created values to codify what makes somebody successful (and love it) at Tinfoil.

Tinfoil’s values guide every employee to make a decision quickly as to whether or not somebody may be a fit for our company. Our values are created as a team and reassessed each year,  during our annual retreat. This is the one work item over a long camping / hiking / bonding weekend. We have a concrete structure around creating and reassessing our values, and so far it’s worked wonderfully. Our approach is to avoid anything that is based solely on emotion and anything that could have a potential HR implication. The other main goal for us was to have our values be debatable; we needed to be able to create a cogent and acceptable argument for the opposite value. Every team values something different, and a value like“innovation” is difficult to argue against (what startup doesn’t want to be innovative?).

Our values today (after iteration over a few years) are:

  • Collaborative
  • Community
  • Curiosity
  • Hacking
  • Integrity 

We are friends with some startup founders who have similar values and some with those that are completely opposite. Collaborative, for example, can be opposed by folks who enjoy making decisions on their own to expedite product development. Curiosity encourages us to try new things (like new programming languages that may be useful), rather than sticking to what we already know. In contrast, many organizations choose to be a Python shop through and through, helping to propagate knowledge and have all engineers on the same page.

Each value we create gets expanded upon with bullet points of things we care about. We often give examples of the value and always denote anti-value behaviors and opposite values.

For example:


  • We strive to build an environment where we’re always willing to pay it forward, even if we have no expectation of any return.
  • We are actively generous to any community we are a part of.
  • We like to lead and help build communities, rather than just support ourselves or follow along.
  • We strive to open-source as much as we can, without compromising company IP.

Examples: VPN builder, rails check, Poodle check, talks we give at conferences, hackathon advisory, donation of time or money to charity, SVLG, consulting with people on open-source or our customers, answering stack exchange questions, etc.

Anti-community behavior

  • Tagging along in a community just for the name.
  • Dismissing the fact that local non-tech communities have an impact on your life.
  • Looking down on any body in a group that you do not ascribe to. (For example, education, class, wealth, experience, race, etc.)

Opposite value: focused entirely on money, self-serving, unwilling to pay it forward 

If somebody on our team starts exhibiting an anti-value behavior, our rule is for anybody to be able to call you out (I even encourage interns to call me out if I’m working against what we care about as a team), you acknowledge, and then we all move on.

Tinfoil is an extremely close-knit team. I care so much about everybody having a voice and empowering them to make important decisions to shape our team. If they can weed out poor culture fits earlier on, it saves us much more time and every hiring decision always becomes easier. Since we implemented our values, we’ve had far fewer debates over whether or not somebody would thrive at Tinfoil. We’re not about survival, but building you up to where you love your job, team, and what you’re learning; we want you to grow, learn from us, and teach us. 

Ainsley Braun

Ainsley Braun is the co-founder and CEO of Tinfoil Security. She's consistently looking for interesting, innovative ways to improve the way security is currently implemented. She spends a lot of her time thinking about the usability and painpoints of security, and loves talking with Tinfoil's users. She also loves rowing and flying kites.

Securing Yourself at DEF CON 26

That time of year is just around the corner again! DEF CON 26 is next week and we here at Tinfoil Security are super excited!

Over the next week the largest gathering of security professionals, researchers, and enthusiasts in the world will be taking place at Caesars Palace and Flamingo Hotels in Las Vegas, NV. The conference is incredible—it consistently ranks among the highlights of the year among nearly everyone I know—but it does have a reputation for being host to all sorts of nefariousness. So if this is your first time going, pay close attention to make sure you have a fun and safe time! 

Why be cautious? Well just as an example, one year during DEF CON, hackers installed a fake ATM in the Rio hotel when it was held there, and used it to steal credit card information. Needless to say, don’t use ATMs at Caesars Palace and Flamingo Hotels if you can help it - bring cash with you. Every year people get owned at DEF CON, but with a little preparation, you can secure yourself against all but the most ludicrous of attacks. Incidentally, while our advice is most applicable to DEF CON and Blackhat, it is also applicable to any other conference you go to. Hackers don’t just hide in holes and hibernate until DEF CON every year - they are everywhere.


DEF CON is known for sporting the “world’s most hostile network.” A good rule of thumb is to assume that any communication going on within 1000 feet of Caesars Palace and Flamingo Hotels are going to be intercepted. If the idea of your phone calls being listened in on, your SMS messages being intercepted, or your web traffic being sniffed bothers you, leave your devices at home. If that’s not feasible, backup and wipe your electronics before the conference: the inconvenience garnered by using a clean laptop for a week is insignificant compared to the damage caused by accidentally leaking source code or other confidential information. This is also true of your mobile device - if you must bring it, back it up and wipe it before and after the conference.

Make sure you are completely up to date on patches, software updates, browser updates, and have the latest AV software. You want to make sure you do this far away from Las Vegas, as downloading anything while in Vegas is probably the worst possible idea. Do not download anything, turn off automatic updates, and be very wary of any “SSL Certificate Errors” you might otherwise have ignored.

Clear your cache, cookies, temporary files, and just about anything else. A lot of websites often cache very sensitive information that can be stolen if accessed by an attacker. Encrypt your data on-disk using full-disk encryption. On Mac, you can do this by setting up FileVault. On Windows, your best bet is probably BitLocker.


If you must bring a phone or a laptop to the conference, keep all of the radios disabled when not in use. Your phone should be in airplane mode, your WiFi should be disabled, and perhaps most importantly, your list of trusted network SSIDs should be cleared - tools like the WiFi Pineapple can spoof access points, trivially allowing an attacker to man-in-the-middle your network traffic. Even the RSA conference, widely regarded as one of the most “professional” security conferences, has had a pineapple as well a few years ago.

The best prevention mechanism for pineapples (if you must enable WiFi) is to disable auto-joining of known networks and delete all of your existing known networks. The way a pineapple works is by listening to your device broadcast its known networks: “Hey, is Tinfoil Security Wireless around?” Then, of course, the pineapple responds: “Yup, I’m right here! Just connect and enjoy your wonderful internet access!” And, by then, it’s game over.

An absolute necessity for network access at DEF CON is the use of a VPN. If you have access to one, use it. If you don’t have access to one, we can help you get set up in five minutes, at no charge. As far as we’re concerned, using a VPN is one of the most important things you can do to secure yourself at DEF CON (or anywhere, for that matter), but it also isn’t sufficient. Even if you’re using a VPN, you should still avoid accessing sensitive information while at the conference. Don’t log into internal services like your company wiki or source control, and avoid checking email at all costs. Be wary of relying on VPNs on mobile devices - it can be difficult to see how traffic is being routed, and whether the VPN is configured properly.

If your phone is acting weird, or wonky, or it looks like you have full LTE service but every call gets dropped: it is a safe bet that you are being intercepted. Turn your phone off immediately, walk somewhere else, and try again. A device “acting weird” at DEF CON is something to be concerned about.

Physical Attacks

Even charging your phone or laptop could result in your device being compromised. It’s not uncommon to see public charging stations scattered around the Caesars Palace and Flamingo Hotels, and as with nearly everything at DEF CON, it should be assumed that these are being used as a vector for exploitation: entire products have been built around protecting users from malicious USB ports.

If you can avoid it, don’t plug anything in at DEF CON, and if you must, bring your own cables: here is a great example of an exploit that was leaked which allows an attacker to eavesdrop on a computer using a modified VGA cable. It sounds absurd, but these are the kinds of attacks you need to be thinking about. Your best bet is to just minimize your exposure surface by reducing your usage of electronics as much as possible.

Social Engineering

Something as innocuous as a “promotional” USB stick giveaway might be an attempt to load malicious code onto your system. Even scanning a QR code might be the first stage in an exploit to root your device. There’s no limit to the creativity of hackers, and if anything is evidence of that, it’s the mind blowing hacks that crop up at DEF CON every year.

If this interests you, you should watch (or participate in!) the Social Engineering CTF. It is incredible what people will tell you if you ask them nicely, and talk with a little confidence. There's even a Social Engineering CTF for Kids. That’s right - every year, Fortune 500 companies have data leaked and stolen by children. If it can happen to them, it can happen to you, so always be a little wary when meeting with new people - most of them will be great, but keep yours eyes out for anything fishy.

ID Badges

For some hackers, getting a free lunch from a company after cloning their VP of Engineering’s badge at DEF CON is the pinnacle of social engineering. There is no reason to bring your company badge or RFID / NFC enabled credit card (the kind you can tap) to DEF CON. If, for some reason, you absolutely have to take it with you to DEF CON, put it in a copper-lined envelope, and wrap it in six layers of aluminum foil (or, as the case may be, tinfoil).

This sounds insane, but these cloning devices are rampant all around the conference, and it's not unheard of for some to be sold on the premises.

Healthy Paranoia

We could go on for pages about the different types of attacks you might run into, and what you can do to protect yourself against them, but really it just comes down to having the right mindset about security - don’t take anything at face value, and assume that everyone is somehow out to exploit you. It sounds scary, but a little common sense goes a long way, and even amidst the fake ATM scares, and things like the Wall of Sheep, DEF CON is an experience that shouldn’t be missed. Nobody likes getting “owned” though, so if it’s your first time, take our advice to heart, and think twice before doing anything that might compromise your security.

If you are going to Blackhat or DEF CON, let us know and ping us at: and we would absolutely love to catch up and buy you a beverage. If there is anything else you’re doing to prepare, let us know: we’d love to hear about it! 

Most importantly, have fun - and stay safe. :)

Shane Wilton

Shane Wilton is the Grand Magistrate of Security at Tinfoil Security, and the company's resident programming language theorist. When he isn't coding in a functional language like Elixir, he's probably hacking on an interpreter for an esolang of his own, or playing around with dependent types in Idris. Security is always at the forefront of his thoughts, and he enjoys building tools which make it easy for other engineers to write secure code. His love for security is matched only by his love for bad movies - and does he ever love bad movies.

Slim Docker Images for Rails

At Tinfoil we’ve been building and distributing our applications with Docker for a few years now. One aspect we value of our Docker images is keeping them small and nimble. By default it’s easy to have a Docker image become bloated because each command introduces a new layer and history of changes to the file system. Luckily there are some tricks to reducing the final image size without squashing all of the layers together.

We can start with a modern Rails application that uses Yarn in addition to Sprockets to manage JavaScript dependencies, Bundler to manage the Ruby gem dependencies, and an expectation that we'll be connecting to an external PostgreSQL database.

A simple starting Dockerfile might look like the one below. We need Node.JS and Yarn installed to precompile our JavaScript assets.

The final image size is 1.11GB! We can start off the weight loss program by combining the commands to install Node.js and Yarn, as well as cleaning up the apt package caches.

That made it a tiny bit smaller: 1.09GB. The ruby:2.5 image is based off of Debian, and has a lot of extra utilities and functionality preinstalled. We’ve found a lot of success making smaller images by basing the image off of Alpine Linux. Most ruby code works fine under Alpine, but since it uses musl instead of glibc, you have to be careful with some C dependencies or ruby gem extensions.

421MB now, so we’re making some nice improvements. We don’t need all of the NPM packages at runtime, so we can use a multi-stage Dockerfile to avoid storing those layers in the final image. Multiple stages split up the build and precompilation steps in their own Docker images, and we can copy out the build artifacts into our final image.

It’s now 231MB, a savings of around 75% 🎉. Note that the `uglifier` gem used by default in Rails 5.2 still requires you to have a Javascript runtime available, otherwise our final docker image could be even smaller.

For the next related post we’ll go over how to use multi-stage Dockerfiles for an Elixir Phoenix project for some more impressive size savings. 

Ben Sedat

Ben Sedat is the Engineering Wizard of Tinfoil Security. He's a bit of a blend between a traditional software engineer (builder) and security engineer (breaker). He spends a lot of time thinking about security: both detection as well as creating solutions for the security issues that exist in software and the internet. He also plays lots of video games. Lots.

Do good with your data at RSA, with Tinfoil Security!

It’s that time of year again! RSA is coming up on April 16th-20th at the Moscone Center in San Francisco and we’re looking forward to seeing you there! We’ll be at booth # 4532, and we’d love to show you our newly launched API Scanner.

This is Tinfoil Security’s second time attending the conference and, based on what we observed last year, we wanted to approach it with a twist. Our goal is to encourage you to think about how much data you share when your badge is scanned, and what you are willing to give up for it. We want you to ask yourself: “What is my data worth?”

At least once during this year’s conference, you’re likely to scan your badge for free swag - a pen, a beer, a t-shirt, or the chance to win a prize. Last year, we were astonished at how much companies had invested in items that would hopefully attract your attention so they could partake in a swag exchange to get hold of your data. Many items you might collect are fun and useful - we love the nerdy things! However, we noticed many people discarding unwanted swag at the end of the conference, only to be picked up by the local homeless population.

This gave us an idea.

We want to provide you with the opportunity to use your data to do good. For each badge we scan, Tinfoil Security will donate a meal to those in need, right here in San Francisco.

To help us with our mission, Tinfoil Security has partnered with the non-profit Curry Without Worry as our 2018 community partner. Curry Without Worry cooks and serves warm, healthy meals to those in need, just blocks from the Moscone Center, where RSA is being held. During our time volunteering with Curry Without Worry, the Tinfoil Security team was surprised to discover it was not just those who are homeless that are in need of a meal, but also college students, off-duty police officers with their children, and city workers. Hunger affects more community members than we realize!

Don’t want your badge scanned at all? Come to our booth (#4532) and we will show you a hack to protect your data! We will also be giving away free pens, stickers, and tattoos - no badge scan required!

In case this is your first time hearing about us: Tinfoil Security provides security tools for developers and DevOps teams. We integrate into your current development workflow, empowering developers to find and fix vulnerabilities as a part of their normal development process. Our goal is to increase bandwidth for your security teams while training developers to code more securely and treat vulnerabilities as normal bugs. Whether you’re building web applications or APIs powering mobile backend servers, IoT devices, and web services, we have a dynamic vulnerability scanner that’s right for you and your team.

More about our 2018 Community partner: Curry Without Worry

Curry Without Worry was founded in December of 2006, as a 501(c)(3) with the purpose of serving soul pleasing food to the hungry people of San Francisco. While they desire to feed people who are most in need, their philosophy is that hunger is not defined by an empty stomach. For this reason, Curry Without Worry is open to all who hunger to join them. The mix of those who accept a meal brings a sense of equality and peace to the experience, allowing those truly having a hard time in life to realize that there are people who care about bringing people from all walks of life together. They serve vegan meals at the Civic Center in San Francisco every Tuesday evening, rain or shine.

You can make a donation directly at:

Don’t forget to visit Tinfoil Security at our RSA Booth # 4532.

If you’ve not yet purchased your ticket, please enjoy a complimentary Guest Expo Pass on us. To sign up, please go to the RSA registration page and enter the expo passcode: X8ETINFO

Tinfoil RSA 2018

Neda Blocho

With a background in running the world's top accelerator program out of Stanford University and a tour as a seed stage investor in Silicon Valley, Neda has seen first hand the great need for solving issues around cyber security! Neda makes sure the world knows how much better and safer their DevOps lives can be by partnering with Tinfoil.

API Security Scanning: How is it done the right way?

We’re excited to announce our API Security Scanner has been officially launched and is now publicly available! It’s a much needed tool we’ve been building and rigorously testing for the past year and a half, and we can’t wait to start sharing it with the world. Before we go into the details on how the scanner works, it’s important to start by discussing the problem of API security in general, and why such a tool is needed in the first place.

First, when we say API, it’s worth clarifying that we’re talking about web-based APIs such as REST APIs, web services, mobile-backend APIs, and the APIs that power IoT devices. We are not targeting lower-level APIs like libraries or application binary interfaces. This is an important distinction to make, because the sorts of security vulnerabilities that affect web-based APIs are going to mirror the same categories of vulnerabilities we’ve spent the past seven years defending against, with our web application security scanner.

Just as web applications can be vulnerable to issues like Cross-Site Scripting (XSS) or SQL injection, APIs can also fall prey to similar attacks. As always, it isn’t quite that simple, and the nuances of how these vulnerabilities are actually exploited and detected can vary dramatically between the two types of applications. In the case of XSS, for example, the difference between a vulnerable API and a secure API depends not only on the presence of attacker controlled sinks in an HTTP response, but also on the content-types of the responses in question, how those responses are consumed by a client, and whether sufficient content-type sniffing mitigations have been enforced.

Also worthy of consideration is how APIs handle authentication, especially as compared to web applications. In the case of web applications, authentication is more or less a solved problem. For the most part, the user visits a page with a login form, enters their credentials, submits the form, and gets back a cookie. There are minor variations to this -- sometimes people store the session in local storage or session storage, for example -- but for the most part, every web application authenticates in pretty much the same way. APIs, on the other hand? Not so much. At an absolute minimum, you need to account for protocols like OAuth2 (and all of its associated grant types!), OpenID Connect, and increasingly, JSON Web Tokens (JWT). Beyond that, it’s also common to layer on other security requirements, like client certificates, or signed requests. Existing web application security scanners have no concept of any of these standards, and even if you managed to get a scanner to authenticate to your API, you’re not going to have much luck coercing it into properly signing your requests.

Lastly, unlike web applications, APIs aren’t discoverable. Unless you’re one of the dozen companies in the world with a HATEOAS based API, it simply isn’t possible for a security scanner to load up your API, follow all of the links, and automatically discover all of the endpoints in that API, let alone the parameters expected by those endpoints, and any constraints required of them. Without some way of programmatically acquiring this information, API security scanning simply can’t be automated in the same way that web scanning has been.

These are all solvable problems, but they mean that a dynamic security scanner needs to be built from the ground up to understand APIs, how APIs are used, and more importantly, how APIs are attacked. This means that simply repurposing an existing web-application security scanner won’t be sufficient (which is what most other solutions currently do). With this point in mind, our API scanner is an entirely new scanning engine (written in Elixir!), built off of everything we’ve learned over the past seven years of attacking web applications.

To handle the previously mentioned authentication issues, we’ve devised a clever system using something we like to call authenticators. Essentially, we’ve distilled API authentication down to its primitives: whether that’s as simple as adding a header or a parameter to a request, or performing an entire OAuth2 handshake and storing the received bearer token for later. From there, our scanner is able to chain together all of these authenticators together, incrementally transforming unauthenticated requests into authenticated requests. Furthermore, because our scanner has such a nuanced understanding of all the discrete steps of an authentication workflow, it becomes possible to detect when any of those steps have failed, and also when any of them aren’t being honored by the server. This uniquely enables us to fuzz the individual steps of an authentication flow, providing us a powerful tool for determining authorization and authentication bypasses.

To address the discoverability issues inherent with APIs, we approached the problem the same way humans do: with documentation! As a developer looking to use a third-party API, your first stop is always the documentation for that API. Historically, this documentation has almost always been presented as unstructured text, and in a form not conducive to being parsed by software. With standards like Swagger, RAML, and API Blueprint becoming more widespread over recent years, the idea of programmatically specifying an API’s behavior is becoming increasingly popular, and this offers an exciting opportunity for API security scanning. In our experience, we’ve found that Swagger in particular is beginning to win out as the de facto standard for API documentation, and so we’ve designed the first version of our API scanner to ingest Swagger documents, and use them to build a map of an API for scanning.

Reading in documentation like this nicely solves the issue of being unable to crawl an API, but it also allows us to scan APIs with a level of intelligence that black-box dynamic web application scanning has never had access to. In most variants of web application scanning, the scanning engine crawls the application to determine all available input vectors: forms, links, buttons, really anything that might trigger some login on the client or server. From there, these inputs are fuzzed to look for security vulnerabilities. The issue, then, is that because this is entirely black box scanning, it becomes difficult for a scanner to ensure it is generating good payloads to send to the web application. By this we mean payloads that, while still being malicious, conform to the format and structure expected by the application. We could send a server every variation of SQL we can think of, but if the server is blocking our requests because they fail the first level of input validation, then we’re never going to make any progress. Our web application scanner actually addresses this very problem by examining the context in which parameters are used, in order to infer their expected structure. By sidestepping this problem entirely with API scanning, we’ve found that we’re able to more easily achieve an even higher level of coverage typically reserved for highly-skilled, manual penetration testing.

By parsing Swagger documentation, though, this problem can be cleverly avoided. Now, in addition to knowing the endpoints to scan, and the parameters on those endpoints, we’re also aware of the types of those parameters and whatever other constraints are specified in the Swagger documentation. It becomes possible for us to know that a given parameter needs to be a string, resembling an email address, of a specific length, and possibly excluding certain characters. Given all of this information, we can begin intelligently generating attack payloads that conform to various subsets of these constraints, allowing us to audit for holes in the server’s intended validation logic, while also giving a suitable jumping off point for intentionally trying to bypass that validation logic with cleverly constructed payloads.

It’s been a long road to get to this point, but we’re proud to have finally built an API security scanner that approaches the problem from a strong foundation, and with careful thought put into what makes API security scanning difficult. We have a lot of enhancements to make, but what we’ve been shipping to customers over the past year has already filled an important gap in their application security program -- especially with our ever present focus on integrating security scanning into the DevOps process. Just as with our web application scanner, our API scanner is designed to be integrated directly into the software development life-cycle, so that developers can find and fix vulnerabilities as early as possible, and often without waiting for a dedicated security engineer to get involved. We facilitate this with first-party integrations for tools like Jenkins, and also by providing a REST API that can drive the entire scanning and reporting process, from start to finish.

Security is much too important to be dealt with as an afterthought. That’s why we always strive to enable our customers push their security up the stack, so they can empower their developers to find and fix vulnerabilities before they become a problem.

Interested in setting up a demo to see for yourself? Find a time that works for you, and schedule a demo right here.

Shane Wilton

Shane Wilton is the Grand Magistrate of Security at Tinfoil Security, and the company's resident programming language theorist. When he isn't coding in a functional language like Elixir, he's probably hacking on an interpreter for an esolang of his own, or playing around with dependent types in Idris. Security is always at the forefront of his thoughts, and he enjoys building tools which make it easy for other engineers to write secure code. His love for security is matched only by his love for bad movies - and does he ever love bad movies.

Tags: XSS security