<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>Secure By Default &#187; Design</title>
	<atom:link href="http://www.securebydefault.info/category/design/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.securebydefault.info</link>
	<description>Designing, building and testing software for better security</description>
	<lastBuildDate>Tue, 10 Nov 2009 12:24:51 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Seam Remoting&#8217;s default allow</title>
		<link>http://www.securebydefault.info/2008/09/08/seam-remotings-default-allow/</link>
		<comments>http://www.securebydefault.info/2008/09/08/seam-remotings-default-allow/#comments</comments>
		<pubDate>Mon, 08 Sep 2008 10:04:46 +0000</pubDate>
		<dc:creator>stephendv</dc:creator>
				<category><![CDATA[Design]]></category>
		<category><![CDATA[frameworks]]></category>

		<guid isPermaLink="false">http://www.securebydefault.info/2008/09/08/seam-remotings-default-allow/</guid>
		<description><![CDATA[Stumbled on another difference in approach between security types and developer types in the Seam remoting functionality.
Remoting makes it a doddle to easily access your Seam server side beans on the client side&#8230; including domain objects.  E.g. if you had a server side bean called User.java:

@Entity
public class User {
    private String [...]]]></description>
		<wfw:commentRss>http://www.securebydefault.info/2008/09/08/seam-remotings-default-allow/feed/</wfw:commentRss>
		<slash:comments>3</slash:comments>
		</item>
		<item>
		<title>Defining security requirements</title>
		<link>http://www.securebydefault.info/2008/01/12/defining-security-requirements/</link>
		<comments>http://www.securebydefault.info/2008/01/12/defining-security-requirements/#comments</comments>
		<pubDate>Sat, 12 Jan 2008 21:02:47 +0000</pubDate>
		<dc:creator>admin</dc:creator>
				<category><![CDATA[Design]]></category>
		<category><![CDATA[Secure SDLC]]></category>
		<category><![CDATA[security requirements]]></category>
		<category><![CDATA[security standards]]></category>

		<guid isPermaLink="false">http://www.twisteddelight.org/security-testing/2008/01/12/defining-security-requirements/</guid>
		<description><![CDATA[The vast majority of security assessments I&#8217;ve worked on have used &#8220;best practice&#8221; to define the security requirements of the application under test.  Clients are content to rely on security assessment firms to decide what should and shouldn&#8217;t be tested, and this is usually OK for bug hunting.  But apart from the well known [...]]]></description>
		<wfw:commentRss>http://www.securebydefault.info/2008/01/12/defining-security-requirements/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>
