Security is way too often seen as a feature instead of a concern. We should not put security on the backlog as features.
Although if we take a look at the backlog we might see some items that are actually security features, these are security features addressing a specific security problem. A login page is used because of a concern that people should only see their own data. "We are concerned that people should only see their data."
Looking at security as a feature might also introduce the following problem: What if added to the previous feature: "we also want the customer to be able to download his data, instead of only seeing it. We also want this to be fast". The result of this extension can be that the team choses to work with physical files. Nobody in the team thought about the security impact and they forgot the lock the physical files away and if a filename pattern emerges people might start to guess and download the data of others.
If we translate this into the real world outside of an IT context we could say that in order to be burglarproof we need a good (expensive) lock. We could add this as a product backlog item and once installed we are good. Or are we? Did we upgrade the hinges as well? No? How did we miss this? Because we described adding the lock as a feature and were lost into thinking about features. We started in a good way, we wanted to be burglarproof and then decided to implement a feature that was not adequate. The concern for security was not met. If we kept looking at it as a concern we could have seen that the hinges also needed to be replaced. We could question who would need a new key and make an inventory of the keys.
Additionally, another reason why we should not look at security as features: Features are prioritized and unfortunately security is often not seen as adding direct business value and therefore it gets lowered in priority for another item.