All complex programs are bound to contain software bugs, of which some could be exploited. These exploits rely on the application being able to start – or become – a process that it should not normally. To exploit these applications in this way, the attacker needs the operating system’s kernel to escalate the attacked program’s permissions or to start another process. Sandboxing is a way of stopping the attacker by limiting, which calls a program can make to the kernel – if a program never does start new processes, the sandbox application intercepts all requests (system calls) to do so. In this paper, I develop a script to collect a list of a program’s used system calls (shortened to syscalls) obtained dynamically by an external tool, and compare its output to existing – static – solutions, which extract a program’s system calls by examining its machine code from the binary. Three out of four tested programs functioned correctly after applying the filter, and the fourth one’s failure may be caused by the program I used to perform the sandboxing – firejail. All four resulting lists were almost half the size of the next best performing tested application. Further research should be done into why one of the applications failed in the same scenario that was used to record the syscalls, and how each syscall’s arguments can be filtered to further decrease the possible attack surface.