11 dev rules former Twitter security engineer Neil Matatall swears by

Neil Matatall hates cross-site scripting. The practice where, roughly speaking, HTML gets automatically generated or gets borrowed from another site. They flat out don’t do it at Twitter, where he was a security engineer for almost three years.

In other words, none of the code on Twitter gets written automatically. Devs just write the code. All the code. No shortcuts.

Matatall explained last Friday at NYU Poly’s Cyber Security Awareness Week Conference 2014.

Matatall will be working security at GitHub soon. Twitter staff presented at the talk two years ago, he said, and this was meant to be an update about their thinking. His fundamental question for the engineers in the room was this: “Are we reacting to vulnerabilities, or are we going re-architect things so that it’s easier to do it the right way?”

Here are some key points about how Twitter thinks about security, which Matatall thought were worth sharing:

1. No code that writes code. “We don’t allow dynamic Javascript,” he said.
2. Secure by default. If everything is built to be secure by default, engineers should have to write code that should raise red flags for others reviewing code if they want to go around it. Scary language like “bypass all security checks” and such should be required. The sort of things that will jump out at reviewers and make them ask, “does it have to be done this way?”
3. Separate code and data. This is a hot topic, but Matatall definitely falls in the camp that data belongs in a database.
4. Tests are your friend. Encourage “negative” test cases. “Things don’t always behave to spec,” Matatall said. “If you spec things out and run a lot of tests, you have a lot more assurance.”
5. Don’t discourage pushing. It’s better to let teams push their code and defend it with both culture and with automatic reviews. If Twitter spots a weakness in code once it’s pushed, the dev gets an instant alert (but no alert once they fix it, because devs don’t want more email).
6. You shall know good code by it’s beauty. “Have you seen an SQL injection query before and after a vulnerability has been fixed?” Matatall asked. “It’s just prettier.”
7. Cultivate a culture of blessed architecture. If you build up a culture where everyone is conscious of building a secure-by-default code base, it will reinforce itself because violating the principles built into the culture will make people feel like jerks.
8. Test as you modify. Use Guard-Brakeman, which automatically runs Brakeman tests on code in the background as you modify files.
9. Open source isn’t always the answer. “The problems that face your organization are very specific to your organization,” Matatall said. It isn’t feasible for Twitter to open source all its security procedures, but they also wouldn’t fit another company.
10. Stats show problems, too. If there’s a spike in stats somewhere, it might not just be because your new feature is so popular. It might be being exploited. This made us think of Sematext’s automatic aberration detection system.
11. Bug bounties are good. People have a lot of motivations for hunting for bugs, but if you put out the word that you’ll pay people who can spot bugs on your site, you will get many new sets of eyes. On that note, Matatall repeatedly said that Twitter had “no unsafe APIs,” which sounded like a bold statement, if any bug bounty hunters are looking for a place to search.

On that last point, Matatall offered the room a maxim from his Twitter colleague, Alex Smolen: “The best indicator of the next bug is the last bug.”

Neil Matatall. (Photo by Brady Dale)