Question: How I should represent Security Requirements if I use User Stories?

* Should they be represented like [special "evil" stories](https://www.owasp.org/index.php/Agile_Software_Development:_Don't_Forget_EVIL_User_Stories)?

or

* Should they be just "invisible" parts of user stories? I.e. if developer implements some User Story, he should already implement it with good security quality.

Answer: 
In Scrum (where User Stories also exist as part of Product Backlog), it is common to see Security, Availability, Speed of response and other non-functional requirements as part of definition of "Done".
This kind of coincides with your notion: 

> 
> I.e. if developer implements some User Story, he should already
>  implement it with good security quality.
> 
> 
> 

This is what Definition of "Done" means- all requirements from the list should be fulfilled in order for the User Story to be considered complete or done.

More on [Definition of "Done"](http://scrumguides.org/scrum-guide.html#artifact-transparency-done)

More on [handling non-functional requirements aka NFRs](http://www.scrumcrazy.com/Handling+Non+Functional+Requirements+in+User+Stories)
You can have a look at how Microsoft approaches this topic. They introduced an idea of Security Development Lifecycle (SDL) which is a software development process that can be used to build more secure software.

One part of this process is activity called Threat Modelling; it's goal is to create a diagram that encapsulates your application interactions and includes both internal and external factors. It helps to identify spots in your application when security threats may occur.

On how to apply SDL and Threat Modelling you can read: <https://technet.microsoft.com/en-us/security/hh855044.aspx>

Hope it answers your questions and will give you at least some overview how to tackle issues like this.