Function as a (More Secure) Service

Lori Mac VittieDistinguished Engineer and Chief Evangelist

There are several modern approaches to application architecture and development that basically take the form of "make it smaller and thus more efficient."

Microservices and Function as a Service (FaaS) both rely on the notion of highly focused code. Now, while it's true that most organizations aren't decomposing applications into hundreds of microservices or thousands of functions, they are gravitating toward this design. This is often because it facilitates Agile development because a relatively small team can design, develop, and then refine a service much more quickly than they can a large, monolithic application. After all, it's much easier to write and test something that is 1000 lines of code than a larger application running into 100,000 lines of code.

But there's another interesting benefit of microservices and FaaS that isn't being touted as much as it should: security.

There are many discussions on the Internet - and I've read a significant number of them - that attempt to nail down the "industry average" defect and vulnerability density. You'll find a wide range of estimates, with some based on actual scans of open source code, and others based on self-reported numbers. NASA, for example, has proudly touted their extremely low defect density as one of the reasons for the success of the space shuttle program. There's also reports based on objectively gathered data from security firms like WhiteHat, but its numbers are focused on vulnerabilities per application and not necessarily per lines of code.

There's no real consensus on defect and vulnerability density except to agree that yes, there is one.

It stands to reason, however, that the fewer lines of code you write, the fewer defects and vulnerabilities are likely to be introduced. Just as importantly, the fewer lines of code you have to search through to find a vulnerability or defect, the faster you're going to find it and, one assumes, fix it.

One of the reasons this is true is scope. If my microservice or function is focused on codifying one aspect of business logic, it requires less logic and fewer libraries to implement. That smaller scope means fewer chances of introducing errors in logic or vulnerabilities in libraries (third-party or otherwise) required to implement that extra logic. Every time you have to include another component or call out to another service you're introducing opportunity for defects and vulnerabilities.

Fewer interfaces to the function or microservice, too, contribute to more secure code. Every interface (an entry point like an API call) introduces the possibility of a vulnerability because you are handling user input. And user input, as we all know, should always be treated as suspect and potentially malicious.

And if microservices reduce the potential for vulnerabilities and defects, then reducing scope even further to a function should further decrease the possibility.

Now, this isn't to say that microservices and FaaS are inherently more secure than their three-tier and monolithic counterparts. Sloppy code is sloppy code, no matter how many lines it takes. But it is true that both architectures lend themselves to development and delivery practices that can lead to more secure code.

Keeping the security benefits in mind as you're evaluating or implementing microservices and/or FaaS can actually help to prevent code from bloating up as well as defending against the introduction of vulnerabilities.

About the Author

Lori Mac VittieDistinguished Engineer and Chief Evangelist

More blogs by Lori Mac Vittie