The past seven years, the threat of "Using components with known vulnerabilities" has ninth in the OWASP TOP-10 rating. We will consider the consequences of using outdated versions of libraries and the interpreter itself. I'll show you how an attacker can exploit known vulnerabilities in the Django and Django Rest Framework, the SQLAlchemy, lxml, PyYAML, and aiohttp-session libraries, and in the Python 2 and Python 3 interpreters themselves.

Every developer expects his app is vulnerability safe. But we all know that such applications do not exist, but we usually deal with not enough tested. This year the Open Web Application Security Project (OWASP) has published TOP-10 most critical vulnerabilities of web applications. I'll tell you what it is and what was changed over the last 4 years from the moment of publication of the previous version. I'm going to explain which types of vulnerabilities are the developer's responsibility and which we can't influence on. I'll show how the popular frameworks help us to develop secure applications and in which situations they can't help.

The code base of our project has more than 50 thousand lines of code. Without good tests, working with so much code would be a nightmare. Many programmers strive for 100% code coverage with tests and believe that this will save them from many problems. I will tell you about the difficulties we faced and why the cherished 100% say nothing about the coverage of the tested code. I will give examples of code and tests that show 100% coverage and show why this is not the case. I'll look at how the library works coverage.py and I will explain why you should not blindly believe the results of her work. I will also share the idea of obtaining an honest metric of code coverage tests and present a prototype of the library, which embodied this idea.

Every programmer sooner or later starts writing tests on his own code. At some point, he starts thinking about how good his tests are. In my report, I will talk about what tools exist to check the quality of tests, how they work and why we are deceived.

Every developer sooner or later comes across domain-specific languages (DSL). We will understand why we need DSL, and what problems they help us to solve. Let's understand in which cases we should develop our own language, and in which — use an existing one. Let's try to draw a line and decide where we have just a library, and where — subject-oriented language. Let's invent our own DSL and compare different approaches to working with it in Python. Let's see how lexical and syntactic analyzers work. Be sure to talk about how to make life easier for users of our language. How to make error messages informative? How to test scripts written in our language? We will be able to answer these questions.

Lecture about what DSL are and when they should be used. I also discussed the different approaches to the development of internal and external DSL in Python and compare these approaches to each other.

The lecture examines how a simple python3 application behaves on different configurations (uwsgi, gunicorn (Eventlet, Gevent)) in conjunction with various repositories (MySQL, MariaDB, PostrgeSQL, MongoDB) under load. Yandex.Tank was used as a means of load generation.